WordPress is in a place where it is “good enough” and don’t have much incentive to become “great”

While still being very far from monopolizing the web, WordPress is a de-facto monopoly in independent web publishing, especially in sites that do not require a complicated editorial process – blogs, promotional sites, small shops and such. It is just so much better than any competition in the area in ease of installation, ease of use, documentation, free support forums, low paid support professionals, it just do not make much sense to use any other tool when you need anything that looks like a CMS on the web.

The problem with being in such a position is that you get sure that you got there from all the things you have done, and it is much harder to pinpoint problematic areas which needs more then incremental improvement, but an actual rethinking. We saw this happen to APPLE (think the original macintosh days, not the current appliances company), MicroSoft, IBM, SUN, each in turn reached a pinnacle of its market segment and just stopped innovating. Microsoft’s Internet Explorer 6 is probably the best example of what happens, once it dominated the market and its bugs became a de-facto standard, MicroSoft dismantled the team working on it, and for years there had been no improvement in it as it was jus good enough. Most of us probably know how it ended, with time it became apperant that there is actually much more browsers can be used for than what MicroSoft assumed.

Is WordPress the equivalent of IE6 in the niche of web publishing? it is very hard to judge such things in real time, it is much easier in hindsight 😉 , but it does seem to me like innovation is on the decline, and if you read the tech sites you get a very negative drift against anyone admitting he uses WordPress.

So, what is my point? Hey this is clearly marked a s a “rant” and rants do not have to have a specific point :)

Not being “nice” and/or “constructive” is very important is software development

I have been told many times on the wordpress stackexchange that I am “not helpful” when I comment on questions or answers, which usually imply that I am obstructing the path someone wants to follow, instead of helping him follow the path.

This is not surprising in a general social enviroment that claims that “you can do everything you want if you just try enough”. Maybe this is a good attitude to have in life, and I actually try to practice it myself and many times I do say things to that effect to other people, but when you come to physics or engineering disciplines, “wanting” is just not good enough. You can not ‘want” the laws of physics to change, and there are solid established reasons why engineering is done in specific way and wanting it to be otherwise was probably already tried and failed during the years.

Therefor a fierce negative feedback, which is not “open to negotiations” is very important as it might save huge amount of time to the person asking the question (or anyone reading an answer). It is very easy to say “why don’t you go and try”, or just ignore the issue, it avoids confrontation and makes you more likeable but if someone tries to follow a path that will lead him to his death, isn’t it better to shout **DON’T GO THERE** instead of answering his question about how much food he should carry?

Should you be rude when you do that? obviously better not to be, but this is not a social club, and there are goals which are more important then politeness, if being rude can save someones life, I will be all for rudeness.

A side note about rudeness on the internet. I actually find it surprising in a way that people get offended from people they don’t know at all. Someone in Alaska thinking I am an idiot is most likely not going to have any impact on my employment or love life, so why should I get worked up over what he thinks?

Usage of PHP’s json_decode on user input should be considered dangerous

No one expects the spanish inquisition and no developer expects that parsing data by itself can lead to a security weakness, but still PHP is always happy to help you have an interesting life.

So what is the problem with json_decode? the problem is that with a properly crafted JSON structure an attacker can force a very slow parsing of the JSON and hang up the CPU. The weakness comes from the way PHP internally stores arrays in memory that in the normal use case is very fast to access and retrieve data, but the worst case is horrible and json_decode by default tries to create an array from a JSON string, Not sure if the object option of the API is any better.

Mitigation? It doesn’t seem like you can guess anything about the content/structure of a JSON string without actually parsing it therefor it is probably a good idea to check that the length of the input “make sense” before processing it.

Smilies are not emojis and vice versa

Saying that smilies are the same (or subset of) as emoji, because both can be used to expresse emotional mode by language neutral graphics, is like saying that french is the same as english because I can use both to buy bread and they use similar character set.

Written language is more then just representation of real and virtual concepts on paper/screen, it also serves to indicate social context. When I am writing in hebrew I can make some assumption about my readers that I can not make when using english.

Smilies are part of the “geek speak”. Geek speak roots are based at the era where communication was slow and text based, and it compromises the quality of the prose in exchange of brevity.

Emojis on the other hand are the language of girls and marketers and it is used when the language skills f the person are not developed enough to write a proper prose, when there is not enough place for proper prose, or when text is just too tuned down for your needs and you want to attract attention.

Both have their valid uses. My niece is more likely to understand the smiling emojy then a “:)” so I will send her an emoji and not a smiley, but if I will use emoji in technical context I will probably be laughed at.

Most software vendors understand that there is a difference, and let you use emoji and smilies even in the same context, except for wordpress which had decided they are the same in version 4.2. What a fail.

wordpress 4.4 is a meh release for most users

WordPress 4.4. had gone RC and while I am far from being a typical wordpress user, so maybe my opinion as a user doesn’t count much, it seems like it has no improvement in anything related to content production and consumption.

The REST API infrastructure is something that in the realm of big organizations. I just can’t see anyone fully separating client and server sides and connecting them with only API request. This is not efficient and will hurt SEO, and while sites that are more of an application then content (think google docs) do not care about  SEO and the performance hit they will be hit with is just nothing to worry about when considering the advantages in software development practices that the separation gives you (good JS developers are easier to find then good PHP ones as almost by definition there are more of them). But for anyone else? The infrastructure can be useful in cutting development time of similar feature but even that is done by very few people.

WordPress as an oEmbed provider is a nice feature but not practical. The problem with oEmbed in general is that you need to trust the source of the embeds and there is just no reason for anyone to trust someone he doesn’t know. This feature can be useful for people that have several sites or in a network, but for people that have one site there is no real advantage of embedding over using some sort of a shortcode that justifies the performance hit that will come from embedding content in an iframe.

Responsive images, in a world in which with everyday mobile bandwidth becomes cheaper and mobile CPUs become stronger, serving an image which is too big is just a not very significant problem, and again people that just post an image from time to time and are not photo bloggers are unlikely to feel the difference. And this is actually the small problem with the feature, the bigger one is that there is no user control on which images are used as alternatives and in theory you might end serving some cropped images and some resized images as alternatives to each other, something that they are obviously not.

The only feature that does make me excited is the taxonomy metadata which will let developers write code which do not feel like a total hack when trying to add features to taxonomies.

Overall, almost nothing to get very excited about, but also nothing to really hate. I think that is the exact definition of the word “meh” :).

Cool tool to debug emails sent from local WAMP/XAMP on windows

I hate myself for not finding the test mail server tool earlier. It is no more then an SMTP server running on the local windows machine that instead of sending the email somewhere else just logs it or opens it in your favourite email client or even text editor.

Could have saved me so much time debugging email related features locally instead of working on a true network connected host.

taming wp_upload_dir to create a directory with the name you want instead of a date

First I guess I need to answer “why” and there are probably two of them

  • Why do I care that it creates a date based directory even if not needed?
    Because I hate to waste CPU cycles if it can be avoided with almost no effort, and I hate to see empty directories when I need to traverse the uploads tree with an FTP software
  • Why not take the base directory from the value being returned and create the directory by myself?
    Because I prefer to trust the core APIs over my own code whenever possible. Core code is tested in real life by millions every day on different platforms and I will probably never test it on more then one. So while creating a directory seems like a very easy thing to do I sill prefer avoid thinking about the possible caveats that might be specific to a specific OS.

The code is actually easy, this is a snippet of something I work on right now

// returns the directory into which the files are stored
function mk_flf_dir() {
  $dirinfo = wp_upload_dir();

  return $dirinfo['path'];

// override the default directory about to be created by wp_upload_dir
function mk_flf_upload_dir($info) {
  $info['path'] = $info['basedir'].'/fast_logins';
  return $info;

The fine point here is to remove the filter after it has done its thing, just because there is a slight chance some other code will want to call wp_upload-dir after your code had run.


Brute force attack on wordpress might bring it down because password validation is hard

There were several discussions about how brute force attacks against WordPress can bring sites down. I have to admit that I didn’t believe that as I never seen anything like that happen and I could not think of any reason for it.

On the face of it handling a login request is very similar to handling any other page request with the small additional cost of one query to the DB that gets the password to authenticate against. Oh boy how wrong I was.

First  it turned out that because of the way the internal data structures are organized, WordPress will try to get all the data associated with the user being authenticated which means that there will be at least two queries instead of one, and it seems like the total time querying the DB doubles. Then, you get into the password validation process which according to security principals is designed to be slow mathematical computation. The mathematical computation is what demands the CPU to work harder which at the end might bring down sites.

I still find it hard to believe that a properly administered site will be brought down that way but at least now it makes theoretical sense.

There is one important thing that I observed while investigating the issue. When trying to login with a user that do not exists the CPU cost is about 20 times lower then the CPU cost when trying to login with a proper user (very non scientific measurement), but the interesting thing is that when trying to login with a valid user, it costs the same if the password was authenticated or not.

Which brings us to the point of user enumeration attacks against wordpress and why core developers are doing a mistake by not addressing it. If it is hard to guess the valid users, an hacker will try all kinds of user/password combinations and it seems like there is a very big chance that most attempt will be against non existing users which are “cheaper” to handle, but if there is an easy way to find out what are the valid users, the attacker will direct all attempts at those users and even if they fail they do cost relatively a lot of CPU to handle.

Sounds like until the core developers will get a grip, an user enumeration prevention plugin is a good thing to have.


Why do WordPress plugins stop being maintained? I guess because of the freeloaders*

*freeloader – someone that uses a free thing without giving back in any way

The problem with getting a software for free, just based on its price, is that the cost of switching to something else is high. Most likely a new software, even if it does exactly the same thing, requires to at least be configured as its DB/configuration files are not compatible with other software and there is no migration utility, and then of course you need to test it to make sure you have duplicated everything correctly.

In a very simplistic way a decision to use a specific software is kind of getting married with the software developer. You might be getting married because that is the easiest way to have available sex, or to get rid of social pressure, but after some time you start to develop dependency on your partner and gain common assets that are hard to divide (kids, house, etc). You might be flirting with some other people but usually the cost of divorce is just too high.
Stopping using a software is like divorcing the developer, the cost is usually high.

Since you don’t want to get to a point were a divorce is the only way forward in a relationship, you are being attentive to your partner because everyone that passed puberty knows that in the real life in order to receive you have also to give.
WordPress users apparently have not passed puberty yet.

The attitude projected by users to the plugin authors is one of entitlement.  Users want the plugins free, want them bug free, want them to perfectly match their own unique needs, want their support questions to be answered in a timely manner and want them to be maintained for ever, stay compatible with every new WordPress version.
The first item – “free”, is in real life contradictory to all the others.

Some people think by mistake that plugin developers can eat their ego, but unfortunately they also need some bread from time to time. 5 starring a plugin is nice but doesn’t help to bring bread to the table therefor forcing plugin developer to look for some real day job that doesn’t leave them any will and energy to spend on maintaining their plugins.

Login LockDown plugin is compatible only up to 4.0.8 and was not updated in a year. It has 200k active users. If every one of them paid one time only a fee of 1$, the developer could have spent 2-3 years doing nothing else but caring to the users of the plugins.

Limit Login Attempts is compatible up to 3.3.2, has not been updated in 3 years but still have more then 1M active users. Now just imagine how much time the developer could have devoted to the plugin if each user donated 1$ to him.

I actually got curious about the later plugin and tried to “track down” its developer. From what I saw on his twitter stream he is doing very well. Obviously he neglects the plugin out of his free will, I guess it is because he can’t eat the 5 star reviews.

People are cheap (news at eleven), me included, but giving some monetary incentive to the developer to keep developing their plugins is good for the users.

In a way this is not only a problem of people being cheap, it is also a problem of the repository for not promoting donations to actively used plugins.

The end result is that the plugins that are in the repository are more of a demo for the real plugin for which you actually have to pay. This is bad because not all the developers that do this have the ability (or will) to run their own plugin update service, leaving the users with no notification about security updates.

Maybe donations of 1$ each are not practical, maybe what is needed is some way in which the repository (or more accurately, the WordPress foundation) sponsor the maintenance of high profile plugins.


update_option will not always save the value to the DB

Yes, I am getting to the point in which I start to call the WordPress core team members “idiots”, at least between me and myself.

Case in point is https://core.trac.wordpress.org/ticket/34689 which is about update_option not always saving values to the DB because it checks the value returned by get_option and performs the write to the DB only if that value is different than the one update_option is requested to save.

Actually sound very logical, right? If the values are the same, what is the point of wasting the resources to write to the DB. The problem is that the value that get_option returns is not the value stored in the DB as several filters might be applied to it, therefor in some situations the value returned by get_option might be the same to the one passed to update_option but still different then the one in the DB.

So why no one had noticed it so far? I think that most people are not aware that you can filter the result of get_option on the one side, and on the other most update_option are made in admin in which the filters mentioned before will not be set as they are useless on admin side.

It is surprising to discover such a bug in one of the lowest level functions WordPress has, a function being used by almost every plugin, but it is just shows that in software when you don’t know about bugs, it doesn’t mean there aren’t any and no matter how battle tried the software is.

What is annoying is the refusal of the core team to admit that it is a bug. In software development there are all kinds of situations in which bugs are results of bad design but once it becomes old enough it is hard to fix it because by then everybody expects it and therefor it becomes a feature. But when a = b do not make a==b true, there is just no way to pretend it is not a bug.