Author: mark

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() {
  add_filter('upload_dir','mk_flf_upload_dir',10,1);
  $dirinfo = wp_upload_dir();
  remove_filter('upload_dir','mk_flf_upload_dir',10,1);

  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.

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

301 redirections should be handled in the application, not .htacces

I see many tips and questions about how to redirect a URL with .htaccess rules. On the face of it, it makes a total sense, why should you waste the time to bootstrap  your website code (which might include DB access and what not), just to send a redirect response, when the webserver can do it much faster for you?

There are several reasons not to do it in .htaccess

  1. Unless you are redirecting most of the site, the rate of hits on a 301 should be low but the lines containing those roles in the .htaccess file still needs to be read and parsed for every url of the site, even those that serve javascript and CSS if you are using the naive approach in writting the rules. In contrast, your  application can check if a redirect is needed only after checking all other possibilities. Each check is slower but the accumulated CPU time spent on this will be lower. This of course depends on your rules and how fast your application determines that there is no match for a URL, and how likely a url is to require a redirect
  2. Statistics gathering. If you do it in .htaccess the only statistical tool you can employ to analyze the redirects is log file and they are rotating and bust a bitch to parse and collect into some better storage system.At the aplication you can simply write the data to a DB, or send an event to google analytics
  3. Your site should be managed from one console, and redirect are more related to a application level configuration then to webserver configuration. It can be very annoying if you write a new post, give it a nice url just to discover that for some reason it is always redirected to some other place without understanding why as your administration software do not know about the htaccess rule, and you probably forgot that it is there (or maybe even someone else put it there).