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?

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” :).

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.

wp_is_mobile is a trap waiting to bite you, just avoid it

What can be wrong with a function that just checks the user agent to determine if the user is on a mobile device like wp_is_mobile? even if the function works as promised the whole idea of using the user agent to detect the type of device on server side is wrong.

Using that function (or any server side detection really, but I focus on wordpress here) violates the core principal of responsive design, that you serve the same HTML to all users.

In practice you will run into trouble once you will want to cache your HTML and then you will start to sometimes get the mobile version of the site on desktop and vice versa. The “nice” thing here is that by that time the original developer had moved on and there will be someone new that the site owner will have to recruit in order to fix the resulting mess. Pros just don’t do that to client.

What is the alternative? Detect whatever needs to be detected using javascript at client side and set a class on the body element. What about people that turn off JS? I say fuck the luddites, let them have a desktop version on their mobile. OK, strike that, make your CSS mobile friendly as much as possible just don’t worry about the UX of the luddites.

Using Jetpack reduces the raw site performance by up to 20%

It is obvious that the jetpack plugin has a bloated code since no one is likely to use all of its modules,  but the interesting question is what is the actual impact of the bloat on the site’s performance.

According to tests done by [art of the jetpack team itself, having jetpack active, without even doing anything will delay the time to first byte (TTFB) by about 70 miliseconds taking 470ms instead of about 400ms.

The point here is not the numbers themselves, as it is not very clear what is the setup of the test, but the fact that it is something that actually going to be noticeable, something that actually requires more server resources.

I assume that the problem is with the time it takes for the PHP interpreter to read and interpret the jetpack source files. People that host on VPS can select a host with faster disk access (SSD), have better control of file caching done in memory by the OS, and cache the interpreted code, can and should optimize PHP interpreting aspects. People on shared hosting are just out of luck.

And the usual caveats regarding any performance related discussion apply – if you have most of your pages served from a cache then the impact performance degradation in generating one page is probably much less important to you.

There is no much point in setting a minimal file size to deflate

Nginx has an directive called gzip_min_length which you can use to instruct it to not bother trying to compress files under a certain size. I spent few hours searching for an apache equivalent setting just to realize

  1. gzipping and deflating, while based on the same compression technology differs in the generate output, especially overhead. By the names of the settings it seems that deflate is the preferred compression on apache, which has also a gzip module, while nginx can only gzip.
  2. For the cost of extra 5 bytes, deflate will send a file that it fails to compress just as it is. For small JS and CSS files, especially after minification, the likelihood of getting a smaller file by compressing it is small, so you will not end up wasting bandwidth instead of saving it unless you are really unlucky (since in the end data is sent in packets of 1k+ bytes in size). Still you waste some CPU cycles for even trying to compress, but since we are talking about small files it should not be too bad, but it would have been nice to have a method to signal apache not to bother (hopefully the compression code does it, but I don’t see any documentation for that).