Category: WordPress

It is better UX to manage widgets in the widget admin than in the customizer

The drive to push everything into the customizer seems to drive people into a religious type of zeal instead of evaluating technical merits, which bring strange enhancement suggestions like putting an non dismissable warning in the widget admin screen https://core.trac.wordpress.org/ticket/40830.

So maybe a explicit explenation is required why people prefer (sometimes) the widget admin screen over working with the customizer

  • Customizer is slow, widget admin is fast(er). In the widget admin there is no need to load all the JS related information that the customizer needs to be able to manage the other aspects of the page which are unrelated to widgets
  • It requires less clicks to get to the widget admin. To get to the admin only two clicks are required 1. login 2. navigate the menu, while with the customizer you need 1. login 2. go to the front end, 3. click the “customize” button, 4. click the “widgets” button.
  • No, the customizer short cuts to the specific widget admin are not really faster. In the admin page it requires 2 click to get to the admin page, two more to open the sidebar and the widget, total 4. On the customizer it requires 3 clicks just to get into the customizer mode, then navigate to the page which includes the widget, then locate the widget on the page (in twentyseventeen a lot of scrolling will be required) and only then you get to the promised land.

This is not to say that the customizer is a pointless thing, but it for sure do not have good answers for many valid mainstream use cases. It is better to stop the zealotry and improve the widgets admin screen (add revisions to widgets and sidebars, widget duplication and the like) instead of spreading FUD about it.

Sin #4 The (dysfunctional) nanny state

All nanny state ideas sound great until you get down to the ways they are being implemented. The manifestation in WordPress is the “automatic update” of core/themes/plugins. The notification in the admin panel as if tells you “There is a new version just install it, it takes less then a minute, and you will have the latest, greatest, and secutitest (just made up the word).

In reality the nanny state promises things that it can not actually check. Does the new version has breaking changes? how was it actually tested to ensure that there are no bugs or security issue? the nanny state just do not know, but still the message is “trust me, I know”.  No wonder people actually buy into that message, after all most of the wordpress site owners have no knowledge about software development and proper ways to run a test on a “testing” site before upgrading production.

And what happens when an upgrade “killed” a site? The owner goes to the plugin/theme developer and tells him exactly what he knows about the profession of his/hers mother. At this moment plugin authors are mystified, after all in the TOS they did not guaranty that any version of the plugin will ever work as expected, and for sure they didn’t ask any site owner personally to upgrade.

So on the one hand the nanny state pushes people to upgrade but on the other refuses to take responsibility to the results, and worse than that, basically there is no way for the plugin author to communicate any possibility of breaking changes, as nanny state do not believe that such things exists.

Instead of teaching people to run tests before installing new version, or forcing hosting companies to provide such facilities, WordPress just pretends it has no responsibility for any breakage.

The plugin and theme repository are not the only manifestation of the nanny state in WordPress, it is less noticeable for most people, but exist in the planning of WordPress events. It is just unbelievable there are people still willing to jump through all the hoops and organize those events.

Sin #3 users are assumed to be software developers

Wait what? didn’t you just say the exact opposite about users being assumed to be technical idiots?

This probably goes back into the days WordPress was created when it was far from being a complete software even if blogging is all you cared about, and you were mostly expected to be able to tweak the CSS, HTML, or add some PHP code. The days before commercial themes, plugins, or even a repository of them.

Those days are in the distant past, but WordPress did not succeed in finding a new balance between removing obsolete features which actually hurt security, and keeping a “hacking” culture. This is why you see the theme and plugin editor as part of WordPress, although just the ability to edit code files in the browser should be a big no-no from security point of view.

Worse, it is being made as an excuse for WordPress not solving security issues. To paraphrase WordPress’s security czar – “It is not our fault it is the fault of the user that didn’t configure his server properly” https://wptavern.com/wordpress-security-issue-in-password-reset-emails-to-be-fixed-in-future-release#comment-219662

It is not just the security aspect, more important is the software development aspect. If you are join to change the code you better save revision in a place from which you can extract them and reinstall them if something bad happens, but WordPress do not offer any such tool. So on the one hand you are encouraged to hack the PHP/CSS/HTML/JS with the most primitive tools around, but there is no support for basic development practices when using those tools.

Software development is not something magical, and to some degree everyone can learn to do it, but as you are unlikely to service your car by yourself all the time, servicing your site should be left to the minority of people who actually know enough to avoid doing stupid things instead of letting people the impression that they can just copy and paste some codes they found on the net.
Changing something is easy, making sure the change is scalable, will not hurt your UX, will not hurt your SEO and social sharing, and most importantly, will be documented so you will remember in two weeks why you have done it in the first place, is not that trivial.

It is as if there is not enough bad software developers that write code for wordpress, from time to time you run into sites which were hacked by their owners, and when they ask you how they can upgrade to the latest wordpress/theme/plugin, the only logical response is to run away.

Sin #2 Treating users as technical idiots, and trying to keep them that way

Famous 5 minutes install, ha? no need to know anything at all about the web, webservers, PHP, MySQL, browsers, javascript, CSS, HTML (short list of things you actually need to know to some degree in order to operate a site for the long term), just upload the software to your hosting and click a button. Oh wait, that is too hard, it requires to setup a DB first and to use an FTP software, lets do it even easier and cooperate with the hosting companies to have a “one click install” in which the user will need to know only the domain name (I guess that with some shared hosting even that is not required), no other technical knowledge required.

Just try to imagine this kind of process in any other aspect of life. For example, you want to drive a car? just go and buy one, 5 minute for the credit card transaction to be approved, 5 more minutes to get the keys and sign documents and you can just drive. Learn how the car operates? Driving laws? what for, it takes too much time.
Even when you buy a commodity appliance like a laptop you are expected to have some basic understanding in the technical aspects, but the WordPress motto is “we serve the lazy and the dumb”.

There is nothing wrong with focusing on serving the dumb and lazy, as long as you are always doing the right decisions, and again with the way the internet changes all the time it is just impossible.  The problem starts when you do not give them any tool to work with when they actually decide that they do want to understand “how it works”. This is why from time to time there is a question on stackexchange about how to secure the login form against brute force attacks, when at least some of the time the people that ask to not even know they have an xml-rpc end point through which they can be attacked.

And when you do not even know there is anything to learn you are unlikely to learn it. A sad positive feedback loop.

Inspired and helped to articulate feelings into words by this great blog post by @rarst.

Sin #1 Market share is the only thing

Sometimes you find yourself at the end of a deep rabbit hole and you ask yourself how did you get there. It is tempting to think that the problem is with you doing a zig while you should have done a zag but rarely you hear people asking what exactly was Alice doing outside by the river with no parental supervision in the first place?

It is pointless to discuss several of WordPress sins without understanding why they came about, and why there are not ever likely to get fixed.

In the beginning, in the good old days when WordPress was just a blogging platform, it was easy to understand the guiding philosophy – make web publishing easy and accessible to all.  This motto worked well and in an era in which you had to have some technical knowledge in order to even buy a domain, it was a major factor in WordPress’s success and in the flourishing of blogging.

Then, two things happened, WordPress decided it wants to be more than a niche blogging platform, but an actual CMS, and Facebook (and to lesser extant twitter) came and killed blogging. This caused a shift in perspective, WordPress do not measure itself anymore in how many bloggers use it (that ratio is declining due to people preferring to “blog” to their friends on Facebook instead of addressing unknown audience), but in how many installs it has.

The problem is that in too many cases quantity and quality do not go hand in hand. It might not be a problem if every decision being made is the right one, but it makes it impossible to change anything for the better if it means that someone’s site will stop functioning. This is true for every type of software but it is even more visible on the web where everything is almost always in a flux.

When you claim that 27% of the web is powered by WordPress, and give the (disputed) number importance it is very easy to see why you are not going to do something that will annoy about 5% (at this point in time) of your users by doing the right thing and dropping support for the EOLed and generally insecure PHP 5.2.

It is actually worse, as with PHP 5.2 there are at least mostly reliable stats on the amount of people that are going be be impacted from a deprecation of support, but there is no usage collection for almost any other feature, and no one dares to suggest changing or even deprecating any of them because the impact is literaly unknown. This leads into the worst kind of stagnation, where even bad decisions has to be preserved.

The Sins of WordPress: Preface

I am going to try to enumerate as many of the WordPress sins as possible (maybe to get it off my chest, maybe to have a place to point to when someone asks me what is my beef with WordPress) but it is very important to remember that everything in life needs to be measured in a context, otherwise all you end up with is just a pointless “holy rage” which might be cool when you need a reason to burn some adrenaline, but unless you are are religious leader or politician, it is very rarely productive in real life.

After all the things are said, the only interesting question for most people is “Is it the best tool to do X in terms of ROI or time to market?” and right now for many things the answer is still a “Yes”.

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

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

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.