Category Archives: Wordpress

Does WordPress v5 aspire to be a static site? Gutenberg fail.

I have been using WordPress for over a decade now, almost exclusively. I’ve had trouble, broken plugins, compatibility issues, white screens of death, and worse. Heck, I remember a time when one of the first things to try when inexplicable problems happened was to reinstall the core. Using FTP.

But these were problems. Something people would tackle and even share fixes back to the community.

What is happening now is worse. It isn’t a bug, it is a feature!

Let us not mince words here.

The Gutenberg editor does not intend to promote WRITING, it promotes layouts.

It is a pagebuilder masquerading as an editor. And a pretty lame one at that with hardly any features compared with the excellent pagebuilders already available – free versions.

And oh, sanity check – not even those are stupid enough to create a new block every time you hit enter on your keyboard. You have to add blocks, or all your paragraphs remain in the same text block, so that you can work on it at the same time.

Because this is a “feature” there is no hope of sharing a fix back and it being fixed. Using the classic editor is at best an emergency temporary measure – that will fall apart sooner or later. For prolific writers, WordPress, the “blogging platform” is a liability now. The second shoe waiting to drop.

Being stupid is no method of idiot-proofing things

The reason WordPress has adopted this nightmare is apparently to make it easy for new users to create websites. But here’s the thing. It already was easy. There is a reason WordPress had such adoption. Convenience.

Writing was simple, straightforward. Designing was plug and play for the most part between themes and page builders. Features were easy to add and in recent times, there also were very few incompatibility issues.

I don’t know how many people will say “Oh, WordPress has a new editor with thousands of smashing 1-2 star reviews, their community is in uproar over functionality and usability, let me try that instead of Wix. I am lacking hassles in life.” But I know that I tried Drupal for the first time in a decade – just to be free of a dumb editor.

Drupal is harder, but it does several things better than WordPress. Speed is one. Semantic content is another. Big sacrifices for a performance focused webmaster, but the ease of WordPress made it a good sacrifice. Take away the ease, throw in a few random hurdles, and there really remains no reason to avoid making an effort to get those.

And whoever has used Drupal knows that it is way more complicated to set up than WordPress. Heck, I’m feeling homesick for an easy and endless array of themes to try out already. Two days of intermittent investigations later, I haven’t even gotten around to figuring out the layouts. With WordPress, my site would have been live by now.

But the balance has tipped. The inconvenience is unfortunate, but like the early days of WordPress when a lot of figuring out had to be done, it is worth it, because the result is something I want.

I will be designing once in a while. I will be writing regularly.

The Gutenberg editor takes the earlier WordPress whimsies – like making it unnecessarily complicated to link to posts on the site in favor of quick “in-line” linking – to a whole new level of inconvenience. When writing, anything that interrupts the flow of thought is a problem. On one hand you have features to remove distractions from the editor. On another, you dump interruptions INTO the editor!

Earlier, you could select a word to link, click the link button and a dialog opened where you could paste a link, select if you needed it to open in a new window, or search for articles from the site to link to – all in one dialog. You could do it almost absently. Use as much or as little of everything possible as you want. You could even use plugins to add classes and such.

With the inline editor, you had to click, and a stupid text field entered next to your selected word to enter the link. If you wanted to do anything else, it was more clicks to the menu next to the text box, select edit, then do your business. And now with Gutenberg, you can create an amazing frontpage daily, but if you want to link to your own content, you’d better open another tab to search your content. And oh, if you click “open new window”, don’t forget to click “enter” as well, because if you just click out, you didn’t make a link at all!

Endless tiny, fiddly clicking that keeps changing places on the screen instead of one click in the predictable location on top of the editor to open necessary functionality. And I don’t even have any bad/jumpy mouse/touchpads that are nightmares for precise clicking. It is faster to simply select a custom html block and hand code your paragraphs and links without taking your hands off the keyboard.

You now are faced with clicking another button if you want to do anything else, then paying attention to that window and actually doing it. And oh, Gutenberg is such a genius that if you enter the link and select “open in new window” and click out, the link DOES NOT GET CREATED, because you didn’t click the tiny enter button as well!

By then you have completely lost your flow of thought, or you write and make a separate pass to add links.

No amount of mad design features are going to compensate for writing convenience.

Editing the flow of text in an article is unnecessarily complicated.

Because each freaking paragraph is its own block, good luck trying to move two lines of one paragraph and the next paragraph to another place in the article where it fits better – something that is simple in absolutely any editor meant for writing – think email, text editors, old wordpress, comment sections of the most primitive sites ever…

But because we are forced to use a freaking page builder to write articles, you can either choose both full paragraphs, or choose the last two lines out of the first paragraph first, move them, then come back to the next paragraph. Spend some time being disoriented scrolling back to where you were if you’re into writing long posts.

Unsatisfying editor area

Large swathes of unused blank space in the editing area, but the editor is this narrow column that doesn’t even use half of it.

I mean, seriously? Is this a joke or what? Why?

This can go on endlessly, like “meta boxes are gone and with it my plugin’s features…. etc”. But it boils down to this.

Lost trust

A platform that threatens the content of my site is like a cheating spouse. Trust is broken. Something precious is at stake. Even if they drop the white elephant later, the memory of how arbitrarily an editor that never got even 50% positive reviews (currently slightly less than 2% and dropping) was made the default for all is forever. How do people with broken sites ever trust that WordPress won’t whimsically destroy their creations again in the future?

Why should people providing free plugins with no commercial profit attached even make the effort to go through learning new methods to upgrade their plugins, if WordPress could make them do it all again with some other whim?

And I’m not someone resistant to change. If the upgrade had value to add, I would learn to live with the inconvenience or use a plugin for my convenience. What is absolutely horrifying is that WordPress has gone ahead with this editor in spite of the terrible reviews – a clear statement that what users want or need is not important. They have gone ahead with inadequate support to features THEY have encouraged the community to plug into – like meta boxes.

We see this in Indian politics, where some crap tech like Aadhaar was pushed through by dumb politicians under the influence of extremely tech savvy opportunists. You don’t expect to see deliberate adoption of hindered usability in a tech project – particularly one on the scale of WordPress AND after receiving extensive feedback from an engaged community.

There are sites with broken layouts, there are sites with broken functionality that depended on specific plugins. Their choice is to not upgrade till their dependencies are met – which could be forever, for plugins not backed by organizations or developers willing to go through new learning curves. Lose/damage years of work or use outdated software (and new plugins won’t work)?

For me, this is the end of WordPress being my default (actually only for a decade) site builder. I still have to decide what to do with the sites already made. Maybe I continue with WordPress. Maybe I’ll move to one of the WordPress forks being created by disgruntled users, but for certain, I am not going to create new sites on WordPress.

Anger done, time to get on with the grieving, coping and moving on.

Transposh translation filter and Yoast sitemaps compatibility

Transposh Translation Filter is a seldom updated, but very useful plugin for running multilanguage sites on WordPress. It is free, it is very intuitive to use and so far, does not appear to slow the site down too much. You can find the plugin here. Due to some differences with WordPress, the version on WordPress is outdated and no longer updated.

While the plugin creates translated page versions, the sitemaps created by the very popular Yoast SEO plugin (earlier known as WordPress SEO) don’t include those pages. The plugin documentation provides a patch that needs to be applied to the Yoast SEO plugin in the class-sitemaps.php file as follows.

/**
* This function integrates with yoast sitemap generator, and adds for each viewable language, the rest of the languages url
* Also - priority is reduced by 0.2
* And this requires the following patch in class-sitemaps.php
* For future yoast versions, and reference, look for this function:
if ( ! in_array( $url['loc'], $stackedurls ) ) {
// Use this filter to adjust the entry before it gets added to the sitemap
$url = apply_filters( 'wpseo_sitemap_entry', $url, 'post', $p );
if ( is_array( $url ) && $url !== array() ) {
$output .= $this->sitemap_url( $url );
$stackedurls[] = $url['loc'];
}
}

And change to:

if ( ! in_array( $url['loc'], $stackedurls ) ) {
// Use this filter to adjust the entry before it gets added to the sitemap
$url = apply_filters( 'wpseo_sitemap_entry', $url, 'post', $p );
if ( is_array( $url ) && $url !== array() ) {
$output .= $this->sitemap_url( $url );
$stackedurls[] = $url['loc'];
}
$langurls = apply_filters( 'wpseo_sitemap_language',$url);
if ( is_array( $langurls )) {
foreach ($langurls as $langurl) {
$output .= $this->sitemap_url( $langurl );
}
}
}
-------------------------------------------------------------------------
* @param yoast_url array $yoast_url Object containing the page information

However, on examining the code of the current version of the Yoast SEO plugin, I found that this function no longer exists at that location. With some experimentation, I found that the file inc/sitemaps/class-post-type-sitemap-provider.php needs to be edited to include the Transposh function. Find this part:

/**
* Filter URL entry before it gets added to the sitemap.
*
* @param array  $url  Array of URL parts.
* @param string $type URL type.
* @param object $post Data object for the URL.
*/
$url = apply_filters( 'wpseo_sitemap_entry', $url, 'post', $post );

if ( empty( $url ) ) {
continue;
}

if ( $post->ID === $this->get_page_for_posts_id() || $post->ID === $this->get_page_on_front_id() ) {

array_unshift( $links, $url );
continue;
}
$links[] = $url;
}

unset( $post, $url );
}

return $links;
}

And change it to

				/**
* Filter URL entry before it gets added to the sitemap.
*
* @param array  $url  Array of URL parts.
* @param string $type URL type.
* @param object $post Data object for the URL.
*/
$url = apply_filters( 'wpseo_sitemap_entry', $url, 'post', $post );

if ( empty( $url ) ) {
continue;
}

if ( $post->ID === $this->get_page_for_posts_id() || $post->ID === $this->get_page_on_front_id() ) {

array_unshift( $links, $url );
continue;
}
$links[] = $url;

/** Transposh Fix */
$langurls = apply_filters( 'wpseo_sitemap_language',$url);
if ( is_array( $langurls )) {
foreach ($langurls as $langurl) {
$links[] = $langurl;
continue;
}
}
/** End Transposh fix */
}

unset( $post, $url );
}

return $links;
}

Hope you find this useful.

your ip 127.0.0.1 has been flagged for security reasons – Jetpack

So I was troubleshooting the configuration on my server and removed all non-essential code. This meant that the proxy was not forwarding the IP address of visitors to the backend.

Imagine my surprise to try to login to post to the blog when I found access to admin blocked with “your ip 127.0.0.1 has been flagged for security reasons find out more“. It had popped up in the login popup wordpress shows when your login has expired and clicking “find out more” does nothing beyond showing a rotating gif indicating loading.

Luckily, I was logged into another blog on the same server which had Jetpack installed as well. Clicking another link on it gave me the same warning on the page instead of a popup and i was able to follow through to the Jetpack site for the explanation.

Apparently to fix this, you have to add

define('JETPACK_IP_ADDRESS_OK', 'X.X.X.X');

to wp-config.php in the root of your wordpress blog. In my case, this was LOCALHOST!

Here’s my irritation with Jetpack.

I have access to the server. What if any other user on the blog had tried to make a post?
I don’t recall activating security. I have another plugin I use for security. I was not even aware that Jetpack offers security. How appropriate is it to activate something that can block access for potential users onto someone’s blog without consent?
What sort of non-consensual inflicted code blocks access to localhost? Surely the forward facing IP and localhost at least ought to be whitelisted by default? Not according to Jetpack, it seems.

This is yet another straw piled onto my back about the ever bloating Jetpack plugin. One of these days, I’m going to take some time to configure alternatives and ditch them.

WordPress: Problem happened with plugin upgrade – can’t delete old files

When you get an error like this while updating, check file ownership. Chances are that you edited something in the backend and the plugin or theme files now being owned by another user, cannot be deleted by the server.

If you have terminal access as root, type:

chown -R www-data:www-data /path/to/wordpress/*

Where www-data is the user your Apache runs as and /path/to/wordpress is of course the path to the root of your wordpress installation. the “*” is to apply to all files and folders and the “-R” earlier means the command [chown – for change owner – in this case] applies recursively to all files and folders contained in the folder named.

If you try to upgrade now, it should work.

Vidyut

Writing || Carnivorous Plants || Artisan soaps || DIY