This document provides tips for keeping a Plone site lean and optimized for small budgets and resources. Some key recommendations include reducing unnecessary content types and products, following standards, isolating complexity, prioritizing memory for hardware, using caching services like Cloudflare, and protecting against malicious bots and crawlers. The overall message is that a simple, flexible design focused on essentials can keep a Plone site performing well even with limited funds.

1. Tone that Plone!
How to keep your site in shape

2. Plone can do it all...
It's the 800 pound gorilla of CMS's
Enterprise.
Heavy duty.
And all that jazz...
But...

3. Plone can do it all...
It's the 800 pound gorilla of CMS's
Enterprise.
Heavy duty.
And all that jazz...
But...
sometimes, too much
of a good thing can be,
well, too much!

4. Back to basics
You're small
The budget is limited
Like, totally unfair...

5. Your mission, should you choose
to accept it...
Fight the flab
Resist the urge to supersize
Plan for the long run
You don't need dodgy diets, wonderpills or an expensive
personal trainer / consultant, just a clear purpose
Remember, staying fit & lean is a process, not a product

6. The planning stage:
Reduce, Re-use, Recycle

7. Reduce, Re-use, Recycle (cont.)
Biggest #fail factor is overdesign.
If your plan is more than 2-3 pages, it probably sucks.
And, it will be outdated next year anyway...
“Just because I can” is not enough justification
for content-types, products or anything else.

9. Reduce, Re-use, Recycle (cont.)
Try to maintain a 'one in – one out' policy on addons
Reduce the content-types
(“News” is just a page with a picture, after all...)
Metadata rules!
As do “Topics”.
Together, they can order most of your content just fine.

10. Recycle bright ideas as well...
There's no shame in using external services. People like Disqus
probably know more about spam-reduction than you, Cloudflare
was born to fight the Slashdot effect.
It's very human to think your organisation is special,
and therefore needs a special navigation and site layout.
You're not. You don't.
Sorry.
“Don't make me think”

11. KISS
Avoid the greatest
& latest framework.
Quite often,
the word 'web-app'
is a codeword for 'frozen in time'. Or 'constant tinkering'.
It can be a step back to that whole 'customized CMS' nightmare.
If your site needs to stay and adapt for a few years,
you should probably be behind the bleeding edge.
It's called that for a reason.

12. Plan sensibly, not frugal
Will your navigation
hold up to hundres of items?
That's why metadata,
and nice ways of searching
like eea.facetedsearch shine...

13. Yeah, yeah, Fashion baby...
Learn to think of
the design of your
site in fashion terms.
Yes, that's the famous
Little Black Dress

14. Haute Couture & Extravaganza
There are only a handful of people on this planet that can get
away with dressing like Lady Gaga.
You're probably not one of them.
Plus, she has 15+ stylists available on a 24/7 basis.
The odds are, you don't

15. That's soooo three minutes ago

16. So, the Little Black Dress it is.
Most women, and quite a few men, will look stylish in it.
Weddings, bar-mitzva's, funerals, or just a regular night,
be confident that you're dressed for the occasion.
Boring? That's why accessories were invented!

17. Now, re-phrase that in CSS
Start with a clear & clean design. Your visitors and users probably
want to see your content, eventually...
Navigation is not fashion, it's function.
Think of it as wearing sensible shoes.
Fonts, on the other hand, are your sunglasses & handbags.
As are some well-placed js effects.
A few bold statements work better than that Carmen Miranda
look. For the uninitiated, that's the whole fruitbowl on your head.

18. Sideline: fashion disasters...
Stuck with a designer that has only done paper?
Be afraid, be very afraid.
Remedy: show the design on a crappy phone to your boss.
Design is like make-up; it should come off gracefully.
(remember that douche-cartouche/trampstamp that
seemed like such a good idea when you were drunk in Thailand...
now think of Flash intro-pages...)

19. Picking Products
Probably the most demanding task a Plonista faces...
Use a set of criteria to pick the right ones, that go further than
technical stuff like unit-tests.
Although these are Good Things (TM), they're not enough.
Before you start, first figure out what problem the Product is
supposed to solve. In 140 characters, please.

20. Social Testing
Documentation. As in, human-readable documentation.
There's a special place in hell for doctest-only docs.
Doctests are, at best, tests. They're not documentation.
If the author can't describe what it does, why should you care?
Well-filled issue tracker. Issues are good. It means other people
use the product. If they get solved quickly, even better.
Get gmane or similar, and check how responsive the author is on
the mailing lists. Gauge reputation.

21. Garlic & Silver
(or, signs that scream: “avoid!”)
The un-install test. On a full test-site, not a clean buildout.
If it doesn't un-install
cleanly, you're on a highway
to upgrade hell.
Do try after adding a few
content items as well
Re-inventing wheels.
They're round, baby!

22. More Garlic & Silver
Not sticking to established industry standards. Yes, the
author may be smarter than the IPTC consortium.
But clout always wins.
Kitchensink Syndrome.
Remember, *nix is good. Small tools for specific jobs.
No i18n. Yes, even if you're from the Anglosaxon world, this is a
bad sign.
Big stacks. They tend to come crashing down harder.

23. I can haz complexity?
Yes, you can. I love Plomino, SQL, ...
The key, however, is to isolate it.
And, double-check those social tests.
“Too big to fail” is a definite plus
in this case!
If all else fails, you can magically rewrite to another instance.

24. Splurge on the Good Stuff!
The wonder of Open Source gives you access to professional tools.
Might as well use them.
Think LDAP. It might sound like overkill, but I use it in sites
with <20 users. And thank myself regularly for it.
Even if you're the sole integrator/developer, keep your stuff in a
repository. Choose your favourite, but do it. That goes for CSS
files, buildout configs, notes to yourself, the lot. Your future you,
or your successor, will be eternally grateful.

25. Maintenance
Do tick-tock buildouts.
That is, have two exact copies of your site. Update the one, test
on humans, then switch the portnumber or symbolic link over.
Then update the other one.
I can guarantee you that pypi will be down otherwise.
And it will put a red sock in your white laundry.
Diskspace is cheap, your sanity... priceless.

26. Deploying on a budget
You will have to learn some basic *nix skills. Nothing fancy, but a
few choice commands can save your day.
Even for small sites, go for ZEO. One ZEO server, one client will
work fine. Zeopack alone is worth it.
Learn to rewrite to canonical URL's. Google will thank you.
My best results: one system-wide NGINX, one system-wide
Varnish, many sites. Consider using system packages.

27. Deploying on a budget (cont.)
It can be done, Plone runs quite well on budget hardware.
Throw all of your limited resources on memory, the processor is
hardly relevant anymore. Aim for 4gig, that'll do quite a few Plone
sites nicely. More is better. Fast HD a bonus.
Don't go for 99.999 % uptime. If that's what you want, ask for
more budget. Cron that restart!
Most sites are brought down not by visitors, but by....

28. Robots, evil robots!

29. Defend against the robocalypse
Get access to raw logfiles. Piwik and Google Analytics are nice, but
they will only see this kind of visitor:
You know, the kind with Javascript
enabled, the kind that
brush their teeth.
They are not your problem.

30. The evil ones
First, get a sensible robots.txt in place that limits access rate, and
do the Google dance to restrict endless links to different
translations and stuff. Google has many options for taming their
bot, although they're non-standard.
Then there's these robots:
They don't listen to robots.txt
So, do what any robot would do:

31. Exterminate !!!
nginx code snippet:
# Dalek attacks - must exterminate (case insensitive)
# The ~* makes it case insensitive as opposed to just a ~
if ($http_user_agent ~* (Baiduspider|Jullo|Yanga|
Yandex|BLP_bbot|ConveraCrawler) ) {
return 403;
}

32. Still in trouble?
Hardware, even leased , is cheap. Throw some more at the
problem. Look outside your national borders. Or, to a place with
fast fibre-to-the-home. Don't go cloud, it gets expensive!
You might want to consider outsourcing your caching even
further.
Look at Cloudflare. It's free, and quite capable.

33. Almost there...
So, with strict planning, a restrained diet and a mind firmly set on
keeping your site from ballooning, a lean, fast, update-proof site
is in the reach of even small, resource-challenged organisations.
All for the new, low price of... next to nothing.
Great! Free cake for all!
But is that right?

34. Does all this make me a bad person?
Yes, it kind of does.
Many times, smallish NGO's
can be the client from hell...
Embrace it. Smaller organisations
can, and do grow. And the
people working there move
on. One day, you may be
a valuable customer.

35. Give back where you can
Bug reports are cool!
Maybe you can help translating, or write documentation.
But, take the time to learn mailing list etiquette, and the rules for
valuable bug reports.
“What would Ajung say” is a very good mind-check!

36. TL;DR?
- cut back on the Product & content-type carbs. Less is more.
- plan flexible. Upgrades, policy reshuffles will occur.
- design should be simple & elegant, spruce up with fonts
- learn to spot good products. Test for tech & social status.
- isolate complexity
- deploy towards max memory, maybe outsource caching
- robots are evil
KTHXBYE!