Posts Tagged ‘WordPress’

'Blog Presentation Tweaks

Sunday, 5 November 2017

I've made some changes to the code that determines the presentation of this 'blog, in order to make it more useable with devices such as cellular phone sets and tablets. Some visitors will observe substantial improvement.

There will probably be more changes to come, and during my attempts to effect such changes, the 'blog may occasionally behave dysfunctionally. If you observe a persistent problem in presentation, even if one long-standing, then please contact me, being as precise as you can about which device, operating system. and browser you use.

Passcodes Redux

Friday, 1 July 2016

To-day, I found myself unable to log-in to this 'blog. I got a diagnostic that I were entering the wrong password. I don't want to burden my readers with a detailed retelling, but what had actually happened was that an up-date of WordPress rejected my password — it wasn't that I were entering the wrong password; it was that the password that I was entering was now prohibitted.

On top of the login code misreporting the problem, the code for resetting the password wouldn't tell me why my password was being rejected. But it was rejected for containing a particular sub-string; and when I removed that sub-string, the password was then accepted.

If you understand passcodes (perhaps in part from reading my previous entry in which they were discussed), then you should see that there is something literally stupid in the WordPress software. Let's say that the forbidden sub-string were 8675309 and that my password were X.52341-hunao-8675309.Y. If I drop the 8675309, the password becomes X.52341-hunao-.Y. That is now accepted, though it is less secure!

If a would-be intruder knew where in the original password 8675309 appeared, and knew the length of the password, then the password would effectively be p1p2p148675309p22p23 where each pi were an unknown character, and the new password would be p1p2p14p22p23 so that the two passwords would be equally secure!. (Either way, an intruder must find a sequence of sixteen unknown characters.) But, as it is, would-be intruders wouldn't be sure that the sub-string appeared, let alone where in the code it would appear, nor how long the password were. One could, in fact, conceptualize the sub-string 8675309 as if it were a single character of extraordinary length (a macro-character) and of great popularity which character might appear within a string of equal or greater length, in which case prohibiting the sub-string would be rather like prohibiting the use of E.

That's not to say that common sub-strings should simply be accepted as passwords or within passwords. A great many systems have been hacked because someone foolishly used passwords such as password, root, or batman. But, instead of rejecting a password because it contained a popular sub-string, the software could, for example, test to see whether the password would be secure if the sub-string were excised, in which case it should be at least slightly more secure if the sub-string were retained.

(Note that this approach works with popular sub-strings of any length, including those of just one character! In fact, when there is no upper-limit on the length of passcodes, they may be securely constructed of nothing but popular sub-strings each of which has multiple characters; a secure password could be made by concatenating ten or more of the one hundred most popular passcodes. Mathematically, the problem of using just one popular passcode is fundamentally the same as that of using a short passcode!)

Sometimes, it's smart programming to write stupid programs, because the costs of designing, implementing, and maintaining more sophisticated software out-weigh the benefits. But, here, the WordPress programmers have opted for cheapness in a way that needlessly thwarts and insults some users, and can actually make systems less secure in those cases. (And the poor diagnostics are simply inexcusable.)

Looked and Felt

Thursday, 26 May 2016

Some days ago, people who consume this 'blog by an ordinary visit with a graphics-enabled browser were confronted with different graphics within the header. The prior and present graphics look like this [image of archaic header lettering, white] but, for a while, the graphics looked like this [image of art-deco header lettering, metallic with grey borders] and then like this [image of art-deco header lettering, the larger being metallic with grey borders and the smaller being white with grey borders]

I had been in the mood to try a change. I constructed some new letters of a general form that I like, which used to be popular for the cover titles of pulps and of comic books. I decided to give them a metallic look (which was done by layering gradient fills of blue-grey).

But my big problem with the results was readability, especially of the subtitle. Changing the subtitle fill from a metallic texture to a solid white helped somewhat, but readability still wasn't what I wanted. The problem was even worse when displayed on my tablet, which resizes images to suit itself and can thereby further blur graphics.

Additionally, though I don't worry a great deal about the æsthetic opinions of others when it comes to my 'blog, both of the people who expressed a preference expressed it for the prior lettering. (One of them declared the newer graphics to be faux-cool.)

I may not be done with these experiments though. I've been thinking of converting the visual theme of this 'blog into a meta-theme, whose graphic components vary, perhaps as a function of time or perhaps randomly or pseudo-randomly.

I have played-around with elements for a distinct presentation to mobile devices, but I note that the screens of typical mobile devices are now fairly large and of high resolution. Meanwhile, the current presentation actually seems pretty good on my agèd cellular phone, which has a screen with a 3.1-inch diagonal, with 480×640 pixels.

Look and Feel

Thursday, 7 May 2015

Some time within the next few days, I'll be testing a revision of the visual theme of this 'blog. Things may, at various intervals, get literally ugly. Please bear with me!

If-and-when the revision is completed, on some displays the look-and-feel of the 'blog may seem perfectly unchanged (though that won't quite be true); but, on wider displays, better use will be made of available space.

If you find that there is a persistent problem with the rendering of this 'blog, then please contact me! Please describe the problem clearly. And, as precisely as you practicably can, please tell me your

  • device (eg, a Dell Inspiron Mini 1012),
  • display-size in pixels (eg, 1024×768),
  • operating system (eg, 64-bit Fedora Core 21, or 32-bit Windows 7 Starter),
  • browser (eg, Opera 12.16)
(If you don't know some of that stuff, then just tell me what of it you do know.)

For now, I am concerned with how the 'blog is displayed on devices whose display-widths are at least 760 pixels. Later, I will attempt to address how the 'blog is rendered on the lower-resolution displays of some mobile devices.

[Up-Date (2015:05/10): The revised theme is now installed and selected. Again, please let me know if you have problems, and in such case please provide the information listed above.]

I'm sorry, Dave. I'm afraid I can't do that.

Thursday, 25 August 2011

This 'blog was off-line for more than 24 hours after an event on the server. A technician at the hosting service ultimately identified the problem as a conflict between a security up-date and the theme — software establishing the appearance (lay-out, color-scheme, &c) of the 'blog. (I find the same conflict when I attempt to use WordPress Default Theme 1.6, upon which my theme was originally based.)

I am told that the administrators can and will change a configuration of the server to allow that theme to be used; but, to get the 'blog back up-and-running in the mean-time, I am temporarily using a very different theme. If, by the time that you read this entry, the 'blog looks pretty much as you're used to seeing it, that means that I have returned to the original theme.

Bugged

Thursday, 16 June 2011

Since some time in April, a bug in the software at LiveJournal.com has kept me from logging into it, and from logging into other sites using that same software, with my OpenID. To-day I received an admission that the problem hasn't been worked and is not likely to be worked any time soon. If you're an LJ friend who posts nothing but Friends-only or otherwise filtered entries, then you might as well write me off.


More generally, my experience filing bug reports has not been very happy. I've recently reported my problems with the formula editor of OpenOffice.

Rather longer ago than that, I noted how WordPress, after letting two dead-lines slip, had just un-scheduled a bug-fix by setting a milestone of Future Release. This morning, I discovered that a spurious claim that the bug was not manifest had caused the report to be closed about three weeks ago. After I was compelled to jump through some otherwise superfluous hoops, it was plainly established that WordPress indeed had exactly the bug that I'd reported (on 29 April 2008), and that, from my initial description, the point of failure could have been quickly found and fixed. A patch was filed, and I thought that the fix would be scheduled for the next bug-fixing release (3.1.4 or 3.2.0, whichever came first), but then the milestone was instead re-set for Future Release. It might still be fixed in the next release, but there is simply no assurance of that. (I can hack my own installation, of course.)

FavIcons, Apple Touch Icons, Site Thumbnail Images, and WordPress

Saturday, 26 February 2011

While someone somewhere has surely written a nice clean, unified explanation on associating favicons, Apple Touch icons, and site thumbnail images with WordPress 'blogs, I've not seen it; and, when it comes to supporting site thumbnail images in WordPress themes, I have seen an awful lot of discussion that is unclear, and PHP code that is inflexible, breakable, or already broken. Perhaps I'm now about to contribute to the problem, but I'm here going to make my own attempt at discussion.

[This entry was written at the suggestion of the Woman of Interest, but she's really not to blame for how it turned-out.]

FavIcons, Apple Touch Icons, and Site Thumbnail Images

First, I'll try to explain the rôles and invocations of these images without peculiar reference to WordPress or to PHP.

Working Code and How to Use It

I think that a great many people are just going to want code that they can drop into a theme, and a practical explanation of how to use that code, so I'll provide such code, with an explanation of how to use it.

PHP and WordPress Coding Issues

A few hardy or lost souls are going to want to know what motivated that code, how it actually does what it does, or what I see might be done differently. (Some of them might do a rather better job than have I.) For those readers, I have prepared a very boring discussion.

Eternity Is Not a Deadline

Sunday, 22 November 2009

As previously noted, back at the end of April 2008, when WordPress version 2.5.1 was the latest stable release, I reported a bug in the handling of nested q[uotation] elements by WordPress. The bug was scheduled to be fixed with version 2.7. Then, as the release of version 2.7 approached, the bug-fix was rescheduled for version 2.9. When I discovered this rescheduling, I wrote

And there seems no assurance that, about half-a-year from now, that target won’t be reset to version 3.1.
Well, that was actually more than 11 months ago, but two days ago, with version 2.9 in beta, the fix was rescheduled for Future Release, which is to say that it really isn't scheduled at all.

I don't really want to dive into the code to fix the error myself. For one thing, I've been thinking of writing an independent software package that would contain some of the same functionality as that of the package in which the bug resides, and I neither want to license the code of someone else nor face challenge as having perhaps cribbed said code. Further, I'd expect to have to invest significant effort to understand the code before I could properly patch it, and might have no use for the understanding after the patch.

Coding Deficit

Friday, 12 December 2008

WordPress version 2.7 has been released.

About eight months ago, when 2.51 was new, I reported a bug that had been giving me grief, a mishandling of the HTML <q> element. WordPress.org automatically set the target of fixing this bug by version 2.7 — which, frankly, to me seemed rather unambitious. It's one thing not to expect to fix a bug in the very next bug-fix release, quite another to put it off for two minor versions.

In any case, I've been looking forward to version 2.7. Now it's out… …and the bug is not fixed. In fact, I've learned that about two months ago, the target was changed to fixing the bug by version 2.9, another two minor versions away. And there seems no assurance that, about half-a-year from now, that target won't be reset to version 3.1.

WordPress — Relative Specification of Directory

Tuesday, 19 August 2008

Amongst other things, I've been hacking at the theme for this 'blog, fixing bugs and simply tweaking things more to my liking. While I'm at this task, visitors are occasionally going to find the 'blog either cosmetically flawed or just plainly dysfunctional. (And, tragically, they may find it thus after I'm finished.)

In the course of my hacking, I wanted to use the PHP function file_exists() to check amongst files within the theme directory. One possibility would be to hard-code a relative specification of the theme directory (the theme slug appended to wp-content/themes/), but that approach isn't robust; it would increase the ways in which the theme could be broken by external change or by cloning.

While WordPress has a function call to return a specification of the directory, it does so in the form of an HTTP URL, notwithstanding that there is a call that explicitly requests the theme URL, to the same effect; meanwhile, PHP function file_exists() will choke on a URL. I went prowling around the WordPress documentation, and did some code-diving, but didn't find a function call or global variable for anything more like a relative specification of the theme directory.

However, there is a function call for the URL of the 'blog — get_bloginfo('template_directory'). My hack to get the relative specification, which could preface file-specs that could be usefully handled by file_exists(), was

substr(get_bloginfo('template_url'),strlen(get_bloginfo('url')) + 1)
The + 1 is to account for the fact that returns to queries to get_bloginfo() for directory URLs don't have a terminal slash.