I’ve recently been playing around with the Statamic CMS for a project and generally I’m impressed. It is a nicely put together CMS that comes without the need for a database.

One thing I have noticed though is that as a developer you can tell this is a relatively new CMS and doesn’t have the maturity and features of something such as WordPress. That said I don’t think it’s planning to emulate the likes of WordPress and wants to be a much simpler system. There is great support via twitter etc and it seems to be growing a community. Which is the key and strength of platforms such as WordPress. So in the spirit of this I’ve shared a couple of plugins I’ve created myself to solve a few little niggles I’ve come across so far.

The first two are related, when using an excerpt there is a truncate feature but the application of it for using a word count leaves an issue of open tags in HTML content and can cause some problems. I’ve put together a basic close tags add on which you can find on github here – Statamic-Close-Tags. However that doesn’t quite work within the truncate function as it is applied.

{{ truncate:words limit="20" }} {{ content|close_tags }} {{ /truncate:words }}

Using close tags there applies the modifier before the truncation. So I’ve created a new words truncate modifier which also closes tags, that one is at statamic-word-truncate and you can apply it quite easily onto the content tag.

{{ content|word_truncate:100 }}

The second issue I’ve had is using the Redactor WYSIWYG editor as it sometimes has issues with smart quotes and Unicode characters (see my post here). So I’ve stuck together a plugin to convert some common trouble makers to unicode characters so they display properly and you’ll find that one here Statamic-kill-quotes.

I’m looking forward to seeing what the upcoming new version of Statamic is capable of but in the meantime I’ll happily use and recommend the current version and hopefully these little plugins can help some other people out.

I’ve been working on a third party API plugin for WordPress that requires a script that auto updates from the API. It consists of pulling a big list of items from the API and checking them against the local site entries, often adding new items or updating existing entries.
The problem was with a number of memory allocation errors with PHP as the script went on, often about half way through the execution. Memory exhausted and Fatal Allowed memory issues popping up. A memory limit change would fix the problem to a point, it would still leave issues though – to work through the full list of items would need a very high PHP memory limit and also what happens if the list gets bigger in future? When 64Mb stops being enough do we simply up it to 128Mb what about when that isn’t enough do we carry on upping it? That still leaves a period where errors are being thrown and updates are missed until it is picked up and the memory limit is upped.

I made sure I called wordpress without themes to reduce a little bit of load and a quick check through to make sure unset() was being used as it should be – I’ll admit my code discipline has been lax in the past with regards to this but as ever we are always learning and making sure that we can improve our techniques. Unsetting things properly to free up the memory is one of those things I now make sure I’m doing rather than just overwriting old variables.
So the script was unsetting as it should and with diligent debugging with php memory usage outputs it became apparent that it was around WordPress functions that the memory usage was going up and not being unset, gradually leading to the errors. Plenty of looking around and eventually I stumbled upon wp_cache_flush and it worked a treat – every time I went around a processing loop or finished a process I called the cache flush and it removed all the stuff WordPress had been storing. I’m sure this wouldn’t be the best fix all for every situation but it’s certainly something to be well aware of.

If you haven’t seen it already Adobe made an announcement yesterday about the future of their Fireworks software. Sadly for those fans of Fireworks it confirms the ever looming spectre that Fireworks is being put to bed and no longer developed.
It does surprise me a little that so many people seem to find this news unexpected, maybe they’ve been ignoring the inevitable? In the last iteration of updates most Adobe products got an updated darker interface, notably Fireworks didn’t, it’s not been looked at favourably for a while – it’s been on life support with Adobe and they’ve pretty much said it’s now do not resuscitate.
Continue reading →

My standard contract (based on Andy Clarke‘s contract killer) includes a clause about creating designs for the latest version of current modern browsers and any older versions will get a workable version of the content. I do of course do some more specific catering for a certain browser if needed but generally building something sensibly and providing the correct fallbacks works well enough for clients.

But sometimes they question why I work this way? I find the best way to explain is with the good old movie making analogy – one I touched upon in an old Smashing Magazine article about using CSS3. It works well as it’s something people are more familiar with, even if they don’t watch a lot of films they will know the terminology and ideas you’re explaining.
So how does the moving making analogy go? A little like this. Continue reading →

I’ve been a long time Google Reader user and I’ve realised that I’ve never really looked much further. I started using it many moons ago and it’s always worked and done what I want so I’ve never looked at anything else.
But Reader is being killed off by Google in July and many people are predicting a decline in RSS usage because of it, I can’t really see that happening. It most certainly won’t be replaced by social media.
Continue reading →