I have done some more technical work on my blogging engine.

I have just spent a lot of time, doing work on my blogging engine – which is “WordPress.org” – to improve the translations. During this time, potential readers may often have seen a screen by WordPress.org, stating that it was in “Maintenance Mode”.

I am hoping that the automated translations will be better in the future, due to the work I just did.

My work was ongoing, from 20h45 through until 01h30



Instant Article versus AMP Showdown Looms.

There seems to be a development on the horizon, which has not hit the front pages yet, but which I think will become a major topic in the near future.

Facebook has announced that it is releasing a “WordPress” plugin, which will allow the creation of “Instant Article” articles, basically on a WYSIWYG basis. This could potentially become big. It should not be forgotten, that Google has a competing software product named “Accelerated Mobile Pages”, or ‘AMP’. This recent news about the WP-plugin, made me aware for the first time that both products exist.

Apparently, the way Facebook Instant Article works, is that the XML which usually makes up an RSS feed, has extended functionality. It would still get fetched from the server via HTTP 2.0 , but should give a better user experience to the owners of smart-phones, who have found for a long time that regular Web-browsing is still awkward from any type of phone. Granted, there do exist Web-browsers that are meant to optimize the layout of text dynamically, as well as versions of many sites that are optimized for phones, but apparently, this all still leaves users wanting.

And so Instant Article XML cannot really be said to be an enhanced type of XML, because the nature of XML is already stated in the acronym: ‘Extensible markup language’. In general, XML may contain definitions of custom tags, followed by actual content that uses these tags. This exists alongside a certain usage of XML, in which the tags are merely defined by a specific application, which uses a similar format to store data.

But Instant Article intends to be XML which contains tags, which some other XML would not contain. And while any advanced browser capable of subscribing to an RSS feed might also be able to view Instant Articles, the main advantage of this format is supposed to be, that it will adapt itself to easier viewing on smart-phones specifically. AFAIK, Facebook is also going to rely on its iPhone and Android apps, to display the Instant Articles in ways that require platform-specific implementation of the XML. Specifically, if the navigation of content is supposed to be possible ‘by tilting the phone’, then this goes beyond what XML tags can do, that are defined entirely in XML.

The Google product ‘AMP’ is supposedly not based on XML, nor on RSS feeds, but rather on HTML, which has added tags, which the browser can interpret due to a JavaScript library. This could be seen as homologous to how ‘JQuery’ can be understood by most browsers, because they are also able to download JavaScript libraries and work with those. But AMP is also designed to adapt itself to the type of browser dynamically, as well as to the size of each display, and give a better user experience than plain-old HTML does.

One aspect which both these products seem to sport, is the intention of providing greater content by way of images and video, and less by way of text. And this is one reason for which private hosting may not play any great role in this area in the near future. For the reader to be fetching this blog from my server, for instance, the browser is only needed to fetch a few kilobytes of data. With images that can turn into megabytes, and with HQ video that can turn into gigabytes.

I would not pretend to have the bandwidth needed, to stream video directly to the readers of my blog. And so there may also be little point, for me to look into ‘Instant Article’ or ‘AMP’ authoring for now.

And yet, the dominance of one of these platforms, or both, is likely to be determined on the basis of authoring, as well as on the basis of hosting / streaming. AFAIK, ‘AMP’ still needs to be coded in a somewhat difficult way, by the content authors. The fact that Facebook is releasing a WordPress plugin means, that affiliated publishers will also be able to create content more fluidly than before. And, the hosting service WordPress.com is likely ‘to have dibs’, before the open source version is released next month, even if WordPress.org users would like to get in on the game.

And so it would seem that the pressure is on Google for the moment. But I’m sure that Google will do what the competition does, which will be to offer something in response.

With Instant Article, the source is to be streamed by way of Facebook itself. With ‘AMP’, Google has already made its Cloud Platform available, to act as an additional component to the system, acting as the ‘AMP-Cache’, by which perhaps a less-restricted set of authors will be able to make content available.

And either way, I think that the usage scenario will be, that more in the spirit of how television used to work, viewers will be able to select their content, by tuning in to a specific feed they’re interested in, maybe to get up-to-date information.

For the past 20 years or so of the WWW,  HTML has dominated the scene. I see this development as a potentially valid form of progress, especially since it does not seem to be providing a monopoly to the providers. I welcome ‘AMP’ and ‘Instant Article’ content to my phone.

As far as my personal blog is concerned, while I cannot stream, I also have a solution. I can upload a video I would like people to see to YouTube, and can drag-and-drop the YouTube links into my blogs. Here, they would form URLs that seem to play as if embedded into my blog entry, while truly being streamed from the Google / YouTube server. For my purposes this should be good enough, since I also do not produce a lot of video footage, which would truly fascinate my blog readers.

And yet in comparison, I also appreciate the fact that there is no regulatory system in place, which would tell me that I cannot use HTML and PHP in this way. And therefore, I also appreciate that the extended usage of XML and JS-libraries, seems to be opening up new possibilities.

Only, I don’t think that many viewers are aware of this yet, since in many cases ‘Instant Article’ and ‘AMP’ are already providing content, in ways that do not need to announce their presence, while working on our phones.



Recognizing that Methodologies Exist, to Computerize Volumes of Text

One feat of Computer Programming which is not in itself forbidden, is to store text in a database, formatted as HTML. But an aspect of this which needs to be recognized, is that random text such as ‘blog entries’, tends to be of variable length, while database records still tend to be of fixed length today.

But, methodologies have existed in Computer Science for a long time, to manage variable-length data. One such methodology involves ‘linked lists’, and another involves ‘doubly-linked lists’. This is commonplace with pointers and memory addresses, but can easily be translated into records with record numbers.

Hence, random text can be subdivided into smaller blocks of arbitrary length, and a table of database records can be defined, such that each record has a numeric field, another numeric field, and then the text field corresponding to a block. Because each record in the DB table has a record number intrinsically, the first numeric field within the record can point to another logical ‘next record’, while the second numeric field to a logical ‘previous record’, just as it was taught with pointers. An impossible record number such as (-1) could be used to signal an end to these chains…

And while this sounds interesting in theory, one type of data processing which “WordPress” already seems to do well, is to keep track of ‘revisions’ that have taken place to a blog entry, each of which could have replaced, inserted or deleted a block of text…

Oh, the marvels of Computing…

I think one would also need to keep track, of the possibility that If a block of text had 256 characters by default, any one block could be using fewer than its full 256 characters…



WordPress.org needs to be adapted to Debian.

I guess that when many people blog, they may go directly to a (paid) hosting service for blogs. WordPress.com would be an example of that. But the assumption that seems to come next, is that people have a Web-hosting service already, with the privileges to FTP files up to it, and privileges to run (server-side) CGI scripts written in PHP. One type of software which they can then upload to this service, can be WordPress.org.

Hence, a lot of the assumptions made in the packaging of WordPress.org, are relevant to this usage scenario, including perhaps the need that can come up to solve technical issues, by tolerating possible configuration changes on the part of the blogger.

What I’m doing is a bit more out of the ordinary, to host my site on my own server, including to host WordPress.org. The way this Web-application is set up by default, it has a root or base directory, plus a content directory that underlies the root. Because many people simply upload this package to their Web-host, and then tinker with it until it works, it’s not an urgent need as seen by the WordPress.org devs, to fend off the root directory as having a username different from the username of the content directory.

But in my setup that’s how it is. And so, entirely because I, too, was tinkering with my setup, I did trigger an attempted core update, which would have rewritten the contents of my root directory. But, because this site’s root has different permissions set on my computer, the WordPress version I use was also unable to give itself a complete update. This is a good thing, because mine was initially installed via my (Debian / Linux) package manager, and I need to keep it compatible with any future updates the package-manager might give it. OTOH, sub-directories of my content directory are supposed to contain more-personalized information.

My enforcement of this was such, that the WordPress.org Web-application was unable to put the site into “Maintenance Mode”, in order to do its core-update. But the fact remains, that even if the site wanted only to update plug-ins or the theme that I happen to be using, this Web-application would still need to put the site into maintenance mode first, which by default it can’t. So by default, even updates to plug-ins would fail.

But my past practice, of just deleting a plug-in from the content directory, and of copying the new version into that content directory – which might be called ‘a manual update’ – will no longer continue to serve me well. From now on, I’ll want to run my updates in-place. And this required some further modification – I.e. some more fiddling on my part, to prepare.

As it stands an attempted in-place update even just for a plug-in, will still fail harmlessly, unless I now do something specific with my root password first. And I’m not going to be more specific than that. I did post some questions on the WordPress.org forums about the issue that I ran in to before, but then just posted my own answer to this issue. It’s just that since nobody did reply to my questions within a few hours of my posting them – until I marked my own issue as Resolved – I also feel that I shouldn’t be wasting their time with more of my details. And without these details, they may not be confident that I really do understand this subject. It’s just that nobody over there even bothered to follow up on that thought, let’s say with any questions of their own.