Michael Eriksson's Blog

A Swede in Germany

Posts Tagged ‘WordPress

WordPress and its user-hostile administration area

leave a comment »

And don’t you believe it: The morons from WordPress still managed to introduce links where they do not belong, despite use of quotation marks.


Written by michaeleriksson

April 8, 2019 at 11:08 am

WordPress and its user-hostile administration area

with one comment

As I tried to refresh a page from my WordPress account earlier today, I found that I had been logged out.* More specifically, I was forcefully lead to (what I assume was) a log-in page that simply did not work or show anything useful, but which complained about a lack of JavaScript. (No, activating JavaScript did not help.) After digging around, I found a log-in page that did work, logged in—and found myself in some version of the administration area that did not even slightly resemble what I was used to, and which simply did not work—with or without JavaScript activated. Problems included incomplete displays, “my sites” simply not being found, and (browser-side) warnings about a possible XSS** attack by a “doubleclick.net” address***.

*Having a dedicated user-account and browser for WordPress, I have no qualms about never logging out manually. Automatic log-outs, on the other hand, are so rare that I cannot even recall the previous time that it happened (or whether I had similar problems back then).

**Cross-site scripting: Roughly speaking, an attempt to cause mischief for a user by including JavaScript from one site into another, in order to circumvent the user’s and browser’s security controls/checks/awareness/whatnot.

***Presumably, a part of Google’s advertising efforts that still carries the name of the former “DoubleClick” brand. The alarm is likely a false positive to the degree that this is almost certainly is not caused by an illegal activity; however, (a) users are still better off without it, e.g. for privacy reasons, (b) the integration into the WordPress pages is obviously not done sufficiently well.

After wasting five to ten minutes trying this-and-that, I contemplated simply foregoing WordPress entirely and effective immediately*, but resorted to a last ditch attempt: One of my old tabs contained a page from the (familiar) admin area. I copy-and-past-ed** it into a new tab, and things suddenly worked as they should.

*WordPress sucks, and I have long-standing plans to move away anyway. However, time constraints and the many other things that I do has postponed this ever again.

**Just re-loading would likely have worked equally well, but keeping the old tab intact gave me a better chance at a second attempt, should something go wrong.

The difference is likely that this link already led to the blog specific admin area, which still works as it should; while what was served after log-in was a user account admin area.* Should the above happen to you (or me, at a future time): Look at the URL. If it begins with “https://wordpress.com/me”, you are probably stuck in the user level area, and you should try to get to the blog area, which will begin with “https://michaeleriksson.wordpress.com/”**. The “dashboard” of the blog administration can then be found under “https://michaeleriksson.wordpress.com/wp-admin/index.php”**, from where other parts of the administration can be found. (In all cases, with reservations for future changes.)

*There can be more than one blog associated with each user account.

**For my main WordPress blog. Please substitute your own blog name/address as appropriate. Also see excursion below.

Excursion on WordPress, incompetent handling of post-by-email, and how this can influence a text:
I have written repeatedly of how WordPress handles post-by-email incompetently, e.g. through introduction of artificial links. This text provides a good example: without the quotation marks around “doubleclick.net” above, it might have been mangled into “http://doubleclick.net” and turned into a link, which is not only contrary to the purpose of use above, but could also be highly confusing to the reader. Knowing of this issue, I resorted to add quotation marks where I would not normally have used them.

The use of e.g. “https://michaeleriksson.wordpress.com/” above is yet another example of why WordPress handles links poorly: I do not intend to link—only to make a statement of how a link would begin. Indeed, going directly to this address would show the published blog—not the administration area. (But here, I would have used quotation marks anyway, because I discuss strings.) Further, “https://michaeleriksson.wordpress.com” would normally have called for a use of place-holders, e.g. in that I had replaced “michaeleriksson” with “[your blog]”. I refrained from doing so, because I see at least a risk* of mangling.

*I have made good experiences with quoting, which seems to protect the text, but if I find an exception I would need to research a work-around, edit, and/or re-publish the text, which would cost me time and energy. To boot, this would involve a delay and inconsistent texts being sent to subscribers. Better then to take the safe road.

Written by michaeleriksson

April 8, 2019 at 11:04 am

Follow-up III: WordPress and more post-by-email distortions

with one comment

I have repeatedly written about WordPress and how it distorts texts posted by email in a user hostile and unethical manner (e.g. in [1], [2], [3]).

Now, I have to add another complaint:

In a text from earlier today, I referenced several web-sites. I deliberately did so without linking and mentioning just the name, e.g. “www.conrad.de”—no link or “http(s):” present. (Should you see one, it is a distortion by WordPress; however, in the past, things within quotes have been left alone.)

Nevertheless the published version appears with full links, including a spurious “http:” at the beginning of the display text of every single instance.

In addition to the general issues already discussed, I note that (a) it is not a given that “http” is a safe choice and “https” would be better in the clear majority of cases;* (b) it must be possible to discuss server (or domain) names without actually linking to them; (c) not everything that looks like a server (or domain) name actually is one and not all servers are necessarily present on the web, which could lead to grossly misleading linking; (d) not linking can be a deliberate choice that is nullified by this idiocy. Notably, considering the odd court decisions that have taken place over the years, a situation could conceivably even occur, where this added link to an address makes someone legally liable in a different manner from merely mentioning the website. Other reasons not to actually link can be related to e.g. search-engine rankings.

*But not always, implying that there is no good choice, and giving a further argument to leave them alone.

Written by michaeleriksson

March 26, 2019 at 10:01 pm

Follow-up: WordPress and more post-by-email distortions

with one comment

Looking at the actual results of the WordPress-spelling issue just mentioned, it seems that all-but-one occurrence of “Wordpress” were indeed turned into “WordPress”—the one that actually was in quotation marks.

This has the advantage that it does allow discussions of spelling and correct quoting of others statements; however, it does so at the cost of an inconsistent behavior, and a behavior that is highly unpredictable. To boot, it does not resolve the overall problem. The correct solution is and remains to keep all occurrences the way that the blogger actually wrote them.

Written by michaeleriksson

January 7, 2019 at 10:53 pm

WordPress and more post-by-email distortions

with 2 comments

I have already written about how WordPress distorts quotation marks in “post by email” texts, and why this is idiotic. However, these are not the only artificial problems caused by WordPress. For instance, I have long noticed that line-breaks are often added or removed compared to the display of my HTML original, e.g. in the list entries in my recent blogroll update. Looking at the actual HTML code, I can see that WordPress has simply removed closing paragraph-tags (p) before a closing-listentry tag (li), which is very poor style. Not only does the result indisputably display differently* in my browser, but good code does not rely on implicit closures of that kind.

*Unlike in my original, very preliminary observations, when I first experimented with post-by-email. Then, I had mainly (or exclusively?) seen a removal of tags around the asterisks that I use for footnotes, which indeed did not seem to affect display. (At least in my browser and with the fonts used—there is always a risk that the situation is different in other circumstances.)

Another issue is that I write “Wordpress” (as I attempt here; let us see whether it is changed) with a small “p”, but that this somehow always turns out as “WordPress” (with a capital “P”). WordPress might have its own preferred spelling, but it has no right to impose it on me, especially since the word could conceivably refer to something else in some context (possibly, within a book by Jasper Fforde?). Certainly, there are a few* people who disapprove strongly of such unconventional casing, and imposing something that it disapproves of in such a manner would be doubly unethical—with strong parallels to a recent text on distortion of literary works. Or what about a text (e.g. this one) discussing the spelling, which is now unable to quote the word in variant forms? Or what about an attempt to quote something that someone else said, which simply did not use the preferred-by-Wordpress spelling?

*I am not one of them, but I have sufficiently strong opinions in other areas that I can sympathize and put myself in their shoes in this scenario.

Moreover: What guarantees do we have that no more insidious changes take place (or later will take place)? What if someone decides that words like “nigger” and “fuck” are to be auto-censored*, that all spelling be converted to U.S. conventions to suit the broadest spectrum of readers, or that all occurrences of “he” be automatically replaced by “they” to ensure PC conformity? Also note that there is no notification whatsoever as to what changes have been made, which leaves the blogger the choice between blind trust and entirely disproportionate checks and/or manual corrections.

*In the context of forums, such auto-censorship is relatively common, and often applied in an utterly idiotic manner. For instance, words like “analyst” can be turned into “****yst”, because the filters do not differ between a stand-alone “anal” and “anal” as part of a larger word with an entirely different meaning. (The question aside, whether “anal” is worthy of censorship in any context.) On the other hand, they are typically foiled by variations like “f*ck” or “F-U-C-K”, the censorship of which would be much less unreasonable (but still disputable!) than a plain-text “anal”.

This is all the more annoying, since one of the reasons that I use post-by-email is to avoid the extreme fuck-ups that WordPress causes through its GUI*.

*Cf. e.g. the current state of a text dealing with “Google’s ideological echo chamber”, where a post-by-email malfunction forced me to correct the text in the GUI—with very weird layout results. (Actually, this might be yet another example of consistent idiocy: I used the HR-tag, which has over-time been redefined from meaning “horizontal ruler” to “general content separator”. Because my original posting attempt was cut off exactly where the HR-tag was, I suspect that WordPress has imposed an even further going private semantic of “end of post”, which would yet again be an inexcusable meddling contrary to reasonable assumptions. However, I have made no further experiments with said tag in conjuncture with WordPress.)

The only reasonable solution is to respect the actual words and code of the blogger.

In order to avoid additional complications through possible WordPress interference, some of the above formulations are less explicit than they would be in another context, e.g. in that I speak of “paragraph-tags (p)” where I would normally have included an explicit tag example.

Written by michaeleriksson

January 7, 2019 at 10:31 pm

WordPress and mangling of quotes

with 2 comments

Preamble: Note that the very complications discussed below make it quite hard to discuss the complications, because I cannot use the characters that I discuss and expect them to appear correctly. Please make allowances. For those with more technical knowledge: The entity references are used for what decimal Unicode-wise is 8220 / 8221 (double quotes) and 8216 / 8217 (single quotes). The literal ones correspond to ASCII/Unicode 34, which WordPress converted to the asymmetric 8220 and 8221. (I stay with the plain decimal numbers here, lest I accidentally trigger some other conversion.)

I just noticed that WordPress had engaged in another inexcusable modification of a text that I had posted as HTML by email—where a truly verbatim use of my text must be assumed.* Firstly, “fancy”** or typographic quotation marks submitted by me as “entity references”*** have been converted to literal UTF-8, which is not only unnecessary but also increases the risk of errors when the page or a portion of its contents is put in a different context.**** Secondly, non-fancy quotation marks that I had deliberately entered as literal UTF-8 had been both converted into entity references and distorted by a “fanciness” that went contrary to any reasonable interpretation of my intentions. Absolutely and utterly idiotic—and entirely unexpected!

*Excepting the special syntax used to include e.g. WordPress tags, and the changes that might be absolutely necessary to make the contents fit syntactically within the displayed page (e.g. to not have two head-blocks in the same page).

**I.e. the ones that look a little differently as a “start” and as an “end” sign. The preceding sentence should, with reservations for mangling, contain two such start and two such end signs in the double variation. This to be contrasted with the symmetrical ones that can be entered by a single key on a standard keyboard.

***A particular type of HTML/XML/whatnot code that identifies the character to display without actually using it.

****Indeed, the reason why I use entity references instead of UTF-8 is partially the risk of distortion along the road as an email (including during processing/publication through WordPress) and partially problems with Firefox (see excursion)—one of the most popular browsers on the web.

The latter conversion is particularly problematic, because it makes it hard to write texts that discuss e.g. program code, HTML markup, and similar, because there the fancy quotes are simply not equivalent. Indeed, this was specifically in a text ([1]) where I needed to use three types of quotation marks to discuss search syntax in a reasonable manner—and by this introduction of fanciness, the text becomes contradictory. Of course, cf. preamble, the current text is another example.

This is the more annoying, as I have a markup setup that automatically generates the right fancy quotes whenever I need them—I have no possible benefit from this distortion that could even remotely compete with the disadvantage. Neither would I assume that anyone else has: If someone deliberately chooses to use HTML, and not e.g. the WYSIWYG editor, sufficient expertise must be assumed, especially as the introduction of fancy quotes is easy within HTML it self—as demonstrated by the fact that I already had fancy quotes in the text, entered correctly.

Excursion of Firefox and encoding:
Note that Firefox insists on treating all* local text as (using the misleading terminology of Firefox) “Western” instead of “Unicode”, despite any local settings, despite the activation of “autodetect”, despite whatever encoding has actually been used for the file, and despite UTF-8 having been the only reasonable default assumption (possibly, excepting ASCII) for years. Notably, if I load a text in Firefox, manually set the encoding to “Unicode”, and then re-load the page, then the encoding resets to “Western”… Correspondingly, if I want to use Firefox for continual inspection of what I intend to publish, I cannot reasonably work with pure UTF-8.

*If I recall an old experiment correctly, there is one exception in that Firefox does respect an encoding declared in the HTML header. However, this is not a good work-around for use with WordPress and similar tools, because that header might be ignored at WordPress’ end. Further, this does not help when e.g. a plain-text file (e.g. of an e-book) is concerned. Further, it is conceptually disputable whether an HTML page should be allowed to contain such information, or whether it should be better left to the HTTP(S) protocol.

Written by michaeleriksson

November 29, 2018 at 8:27 pm

WordPress at it again: Backups and security through obscurity

leave a comment »

The stream of outrageous incompetence by WordPress continues…

For the first time in half an eternity,* I decided to download a backup of my WordPress blog. In the past, this has resulted in (most likely) a zip-file being offered for saving. Today, however, I was met with a message that a link to this zip-file would be sent to my email account… The link, in turn, was valid for a full seven days, downloadable by any arbitrary Internet user, and protected only by (what I hope was) a random sequence of characters added to the file name. This is not only highly user unfriendly—it is also a great example of idiots relying on “security through obscurity”: It is true that no-one who does not know the random part of the file name (obscurity) will be able to download the file (“security”). However, with the state of email security, a great number of hostiles** would have had the opportunity to grab the email contents and find the link. To boot, this approach opens the door for simple errors or oversights by WordPress to open an unnecessary security hole, e.g. if a list with the current such links is similarly weakly protected… Other risks might exist, e.g. that it might be easier for a family member or visitor to get hold of the email/link than access to the WordPress account.*** In contrast, with the old system, the backup was transient and protected by the normal user-account controls—and if those are breached, it does not matter how backups are handled…

*This is not as bad as it sounds: I write all posts offline, with separate backups, in the first place; there are not that many comments; and I intended to leave WordPress at some point anyhow. Correspondingly, little data would actually be lost, if something bad happened.

**Notably, not necessarily parties hostile towards the individual blogger. More likely, it would be someone hostile towards WordPress or who sees WordPress as an easy source of data. Such a hostile would then watch the outgoing traffic from the WordPress mail-servers, grab all the links it could find, and then simply download everything. And, yes, many blogs will contain contents that are not intended for public viewing, including private blogs, blogs restricted to a smaller circle, and public blogs with unpublished drafts.

***Anonymous bloggers are not necessarily known to even a closer circle and even those who are might have contents not yet suitable for viewing by others. (This need not even relate to something truly secret, which would be foolish in the extreme to put on WordPress in any manner, but could include e.g. a draft of a post dealing with an upcoming proposal, surprise party, whatnot.)

If we consider only the delay, there might be see some justification to accomodate extremely large blogs, where there is at least a possibility that the time needed* for the creation of the backup might be too large for normal in-browser interaction. However, if so, the correct solution would be to present the download only within the account it self. Indeed, even if we assume that this type of linking was acceptable (it is not), the procedure is highly suboptimal: The link should have been presented in the confirmation page, not sent per email;** the availability time should have been far shorter (a day?); and the contents should have been deleted or otherwise made unavailable upon download (if something goes wrong, the user can always create a new backup).

*I received the email almost instantaneously, implying that my backup would have had to be at least one, more likely several, orders of magnitude slower than it actually was before this concern became legitimate.

**Or the contents behind an emailed link be password protected, with the password displayed in the confirmation page; or the contents only being served after a successful WordPress login.

Written by michaeleriksson

September 28, 2018 at 7:36 pm