Tag Archives: Wordpress

16May 2013

Using Transients

⋅ Leave a Comment

Transients are a great tool for the WordPress developer. They allow you to easily save temporary data with their own expiry time – simply pass the transients data into the easy-to-use API and it will sort everything out for you. Caching made simple.

Unfortunately, using transients is not without its downsides and recent experiences have shown a couple of issues that any developer should be aware of.

But first I need to explain how transients work.

Transients were not introduced until version 2.8 of WordPress and make use of the WordPress options table (usually named wp_options) to store their data. There aren’t enough fields in this table for the transients to be stored as one record so, instead, it’s split over 2.

Each transient is given, by the developer, a unique name. This is prefixed by either _transient_ or _transient_timeout_ and used as the option_name field. The option_value field is the transient value and the expiry time respectively. You can also store and access network wide transients and these have _site further prefixed to the beginning of the transient name.

So, let’s say you create a transient named ‘test’. Two records will be added to your options table. The first record will be named _transient_test and will have a value of whatever you wished to store in the transient. The second record will be named _transient_timeout_test and the value will be the timestamp of when it expires.

The exception to this rule is if you create a transient that is not set to timeout. In this case only the first record will be created.

If you were creating a network-wide transient then the names would be  _site_transient_test and _site_transient_timeout_test.

How to use Transients

There are 3 simple commands – set_transient, get_transient and delete_transient. The latter two have just one parameter – the transient name.

set_transient, in comparison, has 3 parameters – the transient name, the contents to store and the timeout (in seconds). Set the timeout to 0 for it to never expire.

set_transient and delete_transient both return true or false, depending on their success. get_transient returns the transient content or false if it wasn’t found.

Network-wide transients are handled by the commands set_site_transient, get_site_transient and delete_site_transient. All parameters and return values are as the non-network equivalent.

Problem #1: Transient Name Lengths

The option_name field in the options table has a record length of 64 characters. So, taking into account the prefixes added to the transient name, a transient name can only be a maximum of 45 characters (or 40 characters for network transients). The problem here is that WordPress doesn’t check. It doesn’t fail either – it creates the transients but simply truncates the name. And because each of the transient record pairs has a different length prefix then they each end up with a different name – this means the transient can’t be retrieved.

The Solution

  • WordPress are aware of this and a Trac ticket is open to prevent this from happening. I have updated the ticket myself to ensure they’re aware of the 40 limit for network transients (suggesting that the limit should be a uniform 40 to avoid confusion).
  • The Codex already makes mention of the 45 character limit for set_transient but didn’t mention the 40 limit for set_site_transient. I have now updated the appropriate page to reflect this.

Problem #2: Housekeeping

When you attempt to get a transient and it’s expired WordPress will automatically remove that transient from the table. However, if that transient is never accessed again then it will not be removed.

Why would this happen? Let’s say a plugin uses transients to cache some data. The transient name may be a unique name which represents the options requested – that way, if the user changes the options the, now incorrect, cached data is not used. However, the old transient will never be re-accessed.

To give you an idea of the scale of this I’ve heard one user has over 250,000 transients in his database which have expired.

The Solution

Conclusion

Transients are a powerful and useful tool for the WordPress developer. However, be aware of their limitations and tread carefully!

I’m one of those who are guilty of writing plugins that generate transient names longer than the limit and of generating transients that won’t be accessed once they’ve expired. Now I know all of the above the way I use the transient system has changed.

04Apr 2013

New plugin release – Artiss Vine Embed

⋅ Leave a Comment

VineI’m happy to announce the release of a new WordPress plugin – Artiss Vine Embed.

Just days after Vine released details of how to embed one of their videos into a site, this plugin makes the experience incredibly easy. With both a shortcode for embedding into posts and pages as well as a widget for sidebars it couldn’t be easier.

I’m already working on the next release which will introduce a simple administration screen for setting default options. After that expect responsive video options, amongst other things.

Remarkably this plugin wasn’t the first at WordPress.org to introduce Vine videos (beaten by 2 days!) but it’s already the most feature rich.

25Jan 2013

Automattic for the person

⋅ Leave a Comment

(You see, a nice riff on the REM song name)

Back in January I was a bit “offline” – Artiss.co.uk was certainly extremely quiet. There was a very good reason, though.

Back at the beginning of December I applied for a job at Automattic.I’d applied before but, this time, rather than just send my CV and a small, boring covering letter I thought I’d be a bit, I don’t know, dynamic. Here’s what I wrote…

Dear Automattic, I’m David Artiss, a developer for 29 years (23 of those professionally, the rest as a teenager wrestling with 6510 assembly). Although I write code for an antiquated IBM Point of Sale system during the day, my passion is for PHP, MySQL and, particularly, WordPress. The “Code is Poetry” mantra of WordPress is something I vehemently believe in. Coding is an art – it requires passion, imagination and creativity. I have two blogs (a personal and a technology review blog), both of which are self-installed versions of WordPress. Although my technology blog uses a commercial theme it’s been heavily modified by myself (modifications which I’ve fed back to the theme’s author), including a complete re-write of their commenting system. I’ve also written bespoke competition and review software (which makes use of Rich Snippets to pass review details to search engines). Indeed, I am considering creating my own theme for distribution in the future. However, it’s my work on WordPress plugins that I’m most proud of. I am the owner of 15 plugins (my username is dartiss), 14 of which I authored myself (the other I took over from the original author after he no longer wished to support it any further). My most recent plugin is Artiss Transients Cleaner, which I created after speaking to your own Andrew Nacin. I’d found an issue with the way transients are housekept within WordPress and confirmed with Andrew that this was a known problem. A change to Core is due, but with no current time-scales so I created this plugin to perform the suggested actions that will, eventually, be implemented within Core. Although I’ve not worked on Core, I believe this is a demonstration of the fact that I could do so ably. I’m looking for a change in career and this is just the kind of role I’m craving. I’m more than happy working from home – it’s big, has lots of WiFi (I put extenders everywhere) and I’m on 80 Mbps fibre-optic. It would seem churlish to not make more use of it. My CV is attached. It’s a bit dry, for which I apologise – I’m a bit more dynamic in person and even so more with my code.

I didn’t know if it was a bit too informal but my wife certainly liked it.

A couple of weeks later I was told I was to be interviewed but they had quite a queue so it might be a few weeks. That initial application was, I later came to find, stage 1 of a 5 stage induction process.

Stage 2 came a couple of weeks ago. I had an hour long Skype messaging (not video) conversation with one of their developers. This included some technical questions. I felt it went well, especially when I corrected him on a technicality. After the hour he was happy to move me to Stage 3 – a coding challenge.

I was given an existing plugin to improve in whatever way I felt. I had a week to do it. I turned it around in less than a week and spoke to my Automattic developer soon after. He seemed quite happy at what I’d done but there were a few issue he’s highlighted – security is particularly important to them. Again, I highlighted something he’d missed (he thought I’d not coded something and I had) so potentially gained some points for that (or annoyed him). He gave me a few days to change the code but I turned it around in a day and spoke to him the next night.

I was worried that rushing to make the changes I might have broken something. I didn’t. And the way I solved his issues had impressed him. I was now through to stage 4.

This is when it got exciting.

Artiss.co.uk. One man. Lots of technology.

It even shows up on my WordPress notifications!

I was now officially working for Automattic as a contractor. The idea is that they pay you, per hour, to work on a project. The developer who you’d been assigned would keep an eye on how you’re getting on and let you continue on the project until they’d made a decision either way as to whether you’d failed or passed. This could be days or months.

I get a listing on Matticspace!

I get a listing on Matticspace!

Automattic employees, whether contractors or not, gain access to a site named “Matticspace”.  As people are scattered throughout the world this gives a private “base” for everyone to congregate online. This includes an employee directory, on which I was listed. Matticspace, though, can only be access via a convoluted set-up process that involves generating and submitting security keys from command line.

However, it was at this stage that it all ended. Not by Automattic but by myself. Bearing in mind I still had a full time job, a family and social life there was no way I could realistically fit in the work that they wanted me to (which, by the way, was to make changes to the debug mechanism for Automattic developers within WordPress.com). So I told them I couldn’t do it.

Stage 5 would have been a meeting with Matt Mullenweg, founder and president of Automattic.

At the very least, though, I can say, if for only a brief time, I was working for Automattic. It looks good on my CV too.

21Nov 2012

WordPress Transient Housekeeping

⋅ Leave a Comment
Updates:

A number of my WordPress plugins make use of transients to cache data. However, I’ve had a number of people – mainly relating to Artiss YouTube Embed – highlight the large number of entries this is creating in their Options table. In the case of that plugin I implemented an option that allowed you to clear old transients down and even list the number stored.

Today I had a chance to investigate it further and found a large number of transients that had expired still in my Options table.

So I did what any good WordPress developer would do – went staight to “the horses mouth”. In this case, WordPress Core developer Andrew Nacin.

He confirmed my suspicions – that WordPress doesn’t housekeep transients unless you attempt to access them and they’ve expired. In other words, if you don’t access it then the expired transient remains. In the case of YouTube Embed the transient name is based upon the video parameters – so if you change an option it will generate a new transient name (as it should – you want the video code to update if you’ve changed one of the parameters). Unfortunately, the previous one is no longer accessed and, hence, never gets deleted.

Thankfully, there is hope on the cialis sale horizon – a WordPress ticket is already open to add better housekeeping and Andrew has asked me to nudge him in January so that he can get it included in WordPress 3.6. I’ll certainly be doing that.

Update 1

Rather than be patient and wait for the change I have, instead, created a plugin that will do exactly what was proposed in the aforementioned ticket. I’ve also taken an opportunity to improve on it further by optimising the Options table each time housekeeping is performed.

26Oct 2012

Abandoned WordPress Plugins – an open letter to Matt Mullenweg

⋅ 4 Comments

For those who don’t know, Matt Mullenweg is an online social media entrepreneur and web developer best known for developing WordPress.

Dear Mr Mullenweg,

I love WordPress – I have to say that up-front. Since discovering it a number of years ago, I’ve turned my love of code development towards this fabulous platform, developing a number of sites (mainly for myself) and, eventually, spending time working on and supporting a number of plugins, all available via WordPress.org. And it’s plugins that I wish to talk to you about.

Plugins are one of the big things that really make WordPress what it is – and, particularly, the many thousands developed and maintained by people, like me, who do it for the love of it. Not Automattic employees, but users who contribute their times and energies for free.

You may notice that I said “thousands” of plugins rather than, say, the 21 thousand that WordPress.org currently states. That was on purpose. Do a search of plugins today and you’ll often come across a yellow box that warns you that the plugin is wildly out-of-date and may not be compatible any-more…

The box is a recent addition to the site but is highlighting a problem – people fall out of love. Either with development, a specific plugin or maybe even WordPress itself. Then a plugin becomes abandoned. The result of this is a repository full of broken and un-supported plugins which looks pretty poor, if the truth is known. And if you started using one of these before their abandonment, you may later be left with a broken site after a core update, a desperate scrabble to find the cause, a realisation that a fix for the plugin is not likely and then having to find time, but quickly, to seek an alternative. It’s not much fun.

How big an issue is this? This infographic helps (click for the full graphic)…

36% of the plugins in the repository (nearly 8000 of them) are showing the 2 years or older message.

All of this has come to my attention recently when I spent some time trying to reduce the number of errors being reported by my site. In all cases, I contacted the plugin owners to let them know so that they could look at fixing them in later releases. It was only then that I found plugins that hadn’t been updated for 2 or 3 years.

As a fellow developer I thought I’d look at taking them over – I’m sure I’d read in the forum somewhere that you could. So I contacted WordPress support and asked to be given access to what were, blatantly, abandoned plugins. The response, though, was not what I was expecting…

We don’t hand over plugins at this time (we may in the future, but we have a no-consensus on it today).

We suggest you fork the plugin (i.e. make a request to host your own) with a new name.

For something that makes WordPress looks rather un-professional this appears to be a glaring over-sight. In the case of the particular plugin that I initially contacted support about, it was already a fork from an existing abandoned plugin, so creating a third version in the archive would, well, look rubbish (but inflates the number of plugins by 3) – it would also mean starting the user base from zero, leaving behind all of the existing users.

As it turned out, I was able to get hold of the developer but he didn’t want me to take it over as I was a “stranger”, instead adding it to Github where other “strangers” could contribute instead. I later contacted another developer who had also left one of his plugins (he works for Automattic) but he didn’t even bother responding.

Of course you don’t want people taking over plugins’ when, rather than abandoned, the owners has simply not had to update it for a while. Some checks and measures do need to be put into place, but I hardly think this would be difficult . Here, for example, is my suggestion…

  • Once the “2 year” message is generated, send an automated email to the developer. This would ask them to confirm that they are still supporting the plugin – a link to a form would allow them to confirm this or mark it as abandoned.
  • If there is no response after,say, a month a reminder mail would be sent. If this is not responded to, the plugin would be automatically marked as abandoned.
  • Once abandoned, the plugin will no longer appears in the plugin  lists (or statistics!). However, they can be viewed separately so that developer can request to take ownership. Once another developer takes over it will return, seamlessly, to the lists so that users will be able to upgrade their existing version.

There is a lot of great stuff in the archive and there is no need for duplication or old, broken code. A

smaller repository of quality plugins will always reflect better on WordPress than something larger but of variable quality.

Can I also make another request on behalf of the plugin developer community? Could WordPress.org look at promoting our work a little better? The plugins front page lists “Featured Plugins”, a great opportunity for you to help those people creating free plugins for your system. It’s such a shame that every single one is authored by a member of WordPress.org or Automattic.

There is a “Most Popular” list but this is dominated by similar plugins and hardly helps promote the “up and coming” developments.

Considering the vast number of WordPress installations that have some lovely “feature sliders”, this is sadly lacking from a page that could really do with one. Can I suggest that promotion of non-internal plugins would be helpful, along with a scrolling slider? At the very least, the former suggestion would be gratefully appreciated, I’m sure.

Thank you for reading.

David Artiss.
WordPress plugin developer.

Top
%d bloggers like this: