mark | mark kaplun's blog

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

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.