Technology Tales

Adventures & experiences in contemporary technology

Turning off the full height editor option in WordPress 4.0

10th September 2014

Though I keep a little eye on WordPress development, it is no way near as rigorous as when I submitted a patch that got me a mention on the contributor list of a main WordPress release. That may explain how the full editor setting, which is turned on by default passed by on me without my taking much in the way of notice of it.

WordPress has become so mature now that I almost do not expect major revisions like the overhauls received by the administration back-end in 2008. The second interface was got so right that it still is with us and there were concerns in my mind at the time as to how usable it would be. Sometimes, those initial suspicions can come to nothing.

However, WordPress 4.0 brought a major change to the editor and I unfortunately am not sure that it is successful. A full height editor sounds a good idea in principle but I found some rough edges to its present implementation that leave me wondering if any UX person got to reviewing it. The first reason is that scrolling becomes odd with the editor’s toolbar becoming fixed when you scroll down far enough on an editor screen. The sidebar scrolling then is out of sync with the editor box, which creates a very odd sensation. Having keyboard shortcuts like CTRL+HOME and CTRL+END not working as they should only convinced me that the new arrangement was not for me and I wanted to turn it off.

A search with Google turned up nothing of note so I took to the WordPress.org forum to see if I could get any joy. That revealed that I should have thought of looking in the screen options dropdown box for an option called “Expand the editor to match the window height” so I could clear that tickbox. Because of the appearance of a Visual Editor control on there, I looked on the user profile screen and found nothing so the logic of how things are set up is sub-optimal.  Maybe, the latter option needs to be a screen option now too. Thankfully, the window height editor option only needs setting once for both posts and pages so you are covered for all eventualities at once.

With a distraction-free editing option, I am not sure why someone went for the full height editor too. If WordPress wanted to stick with this, it does need more refinement so it behaves more conventionally. Personally, I would not build a website with that kind of ill-synchronised scrolling effect so it is something needs work as does the location of the Visual Editor setting. It could be that both settings need to be at the user level and not with one being above that level while another is at it. Until I got the actual solution, I was faced with using distraction-free mode all the time and also installed the WP Editor plugin too. That remains due to its code highlighting even if dropping into code view always triggers the need to create a new revision. Despite that, all is better in the end.

Easier to print?

20th February 2010

One matter that really came to light was how well or not the pages on here and on my hill walking and photography website came out on the printed page. After spotting a WordPress Codex article and with an eye on making things better, I have made a distinction between screen and print stylesheets. The code in the XHTML looks like this:

<link rel=”stylesheet” href=”/style.css” type=”text/css” media=”screen” />
<link rel=”stylesheet” href=”/style_print.css” type=”text/css” media=”print” />

The media attribute seems to be respected by the browsers that I have been using for testing (latest versions of Firefox, MSIE and Opera) so it then was a matter of using CSS to control what was shown and how it was displayed. Extraneous items like sidebars were excluded from the printed page in favour of the real content that visitors would be wanting anyway and everything else was made as monochrome as possible with images being the only things to escape. After all, people don’t want to be wasting paper and ink in this cash strained times and there’s no need to have any more colour than necessary either. Then, there’s the distraction caused by non-functioning hyperlinks that has inspired the sharing of some wisdom on A List Apart. Returning to my implementation, please let me know in the comments what you think of what I have done on here and if there remains any room for improvement.

Some oddness with table cell display in Opera resolved

14th July 2009
Sidebar displayed in Opera

Blog sidebar displayed in Opera before fix was applied

A while back, I reported a baffling problem with Opera managing to miss out an entry in the calendar widget on my hillwalking blog. After a bit of fiddling, I managed to track down the problem: setting position:relative in the CSS for hyperlink tags on my theme. Commenting out CSS declarations may seem a low technology way of finding problems like this but it still retains its place as this little episode proves. Changing it to position:static for the hyperlinked numbers in the table fixed the issue while I left the defaults as they were in case they had an adverse impact elsewhere. If all of this sounds rather too empirical in its approach, then I can only agree with you but a fix is a fix nonetheless. However, display:block is also set for the table entries so that may have a part to play too. Regardless of the trial and error feel to the solution, I could not find the problem documented anywhere so I am sharing it here to help any others who encounter the same sort of weirdness.

Why my blogroll is no longer a widget

30th June 2007

I have taken what some might consider a retrograde step: I added code to insert my blogroll directly below the widgets section of my left-hand sidebar. The reason for this is reuse of the same ID; it causes my Firefox HTML Validation add-on to issue warnings and so can hardly be standards compliant. Ironically, in its native state, the blogroll functions take panes to ensure that each category has its own ID, only for the widgets functions to go and disregard all of this and assign the same ID for each category. To change this in the widgets code involves ploughing through loads of arrays (and functions) and is not something for which I have time when an easier solution is very much possible.

Using blog widgets

13th May 2007

The theme that I am using for this blog, Andreas09, allows me to add widgets to the sidebars. And most of these are customisable to varying extents. I have selected a few for mention here but there are others like Tag Clouds (very Web 2.0 and, I think, very inelegant) available too.

The most customisable of all is the Text widget; you can add practically any (X)HTML to it and it’s how added my online photo gallery teaser. Don’t try adding any scripting or it will be removed for security reasons. Even JavaScript suffers this inglorious fate and I wouldn’t be surprised if it was the same for PHP.

Next up in usefulness, at least from the content point of view, are RSS feeds (just look for the headings with the orange logos beside them). The ability to show shared items from you Google Reader is a nice piece of convergence. Speaking of convergence, I also added the feed from my hillwalking blog too. Taking things further again, I have added ones for InternetNews, A List Apart and The Blog Herald and I wonder if RSS feeds will not replace email newsletters now that we have tools like Google Reader.

Moving to the navigation side of things, the Categories widget can be collapsed to a drop down menu like I have for the Archives one. I prefer things to be the way that I have them because I want people to see what’s here. The Calender widget makes up for visitors not spotting what the drop down represents; that’s why the Archives widget can be a drop down menu rather than a list.

HennessyBlog theme update

12th February 2007

Over the weekend, I have been updating the theme on my other blog, HennessyBlog. It has been a task that projected me onto a learning curve with the WordPress 2.1 codebase. I have collected what I encountered so I know that it’s out there on the web for you (and I) to use and peruse. It took some digging to get to know some of what you find below. Any function used to power WordPress takes some finding so I need to find one place on the web where the code for WordPress is fully documented. The sites presenting tutorials on how to use WordPress are more often than not geared towards the non-techie rather than code cutters like myself. Then again, they might be waiting for someone to do it for them…

The changes made are as follows:

Tweaks to the interface

These are subtle with the addition of navigation controls to the sidebar and the change in location of the post metadata being the most obvious enhancements. “Decoration” with solid and dashed lines (using CSS border attributes rather than the deprecated hr tagset) and standards compliance links.

Standards compliance

Adding standards compliance links does mean that you’d better check that all is in order; it was then that I discovered that there was work to be done. There is an issue with the WordPress wpautop function (it lives in the formatting.php file) in that it sometimes doesn’t add closing tags. Finding out that it was this function that is implicated took a trip to the WordPress.org website; a good rummage in the wp-includes folder does a lot but it can’t achieve everything.

Like a lot of things in the WordPress code, the wpautop function isn’t half buried. The the_content function (see template-functions-post.php) used to output blog entries calls get_content function (also in template-functions-post.php) to extract the data from mySQL. The add_filter function (in plugin.php) associates the wpautop function and others with get_the_content function and the p tags get added to the output.

To return to the non-ideal behaviour that caused me to start out on the above quest, an example is where you have an img tag enclosed by div tags. The required substitution involves the use of regular expressions that work most of the time but get confused here. So adding a hack to the wpautop function was needed to change the code so that the p end tag got inserted. I’ll be keeping an eye out for any more scenarios like this that slip through the net and for any side effects. Otherwise, compliance is just making sure that all those img tags have their alt attributes completed.

Tweaks to navigation code

Most of my time has been spent on tweaking of the PHP code supporting the navigation. Different functions were being called in different places and I wanted to harmonise things. To do this, I created new functions in the functions.php for my theme and needed to resolve a number of issues along the way. Not least among these were regular expressions used for subsetting with the preg_match match that weren’t to my eyes Perl-compliant, as would be implied by the choice of function. I have since found that PCRE’s in PHP use a more pragmatic syntax but there remained issues with the expressions that were being used. They seemed to behave OK in their native environment but fell out of favour within the environs of my theme. Being acquainted with Perl, I went for a more familiar expression style and the issue has been resolved.

Along the way, I broke the RSS feed. This was on my off-line test blog so no one, apart from myself, that is, would have noticed. After a bit of searching, I realised that some stray white-space from the end of a PHP file (wp-config.php being a favourite culprit), after the PHP end tag in the script file as it happens, was finding its way into the feed and causing things to fall over. Feed readers don’t take too kindly to the idea of the XML declaration not making an appearance on the first line of the file. The refusal of Firefox to refresh things as it should caused some confusion until I realised that a forced refresh of the feed display was needed -- sometimes, it takes a while for an addled brain to think of these kinds of things.

Interesting gotcha

7th February 2007

I have just spotted an interesting behavour in the Recent Posts section on the left sidebar here: the space between the penultimate and final words in a heading is the HTML entity for a non-breaking space rather than a real space. That means that a browser sees the two words as one rather than two strings and has consequences for text wrapping of these last two words in the phrase. The workaround is to watch the lengths of the last two words but why things were set up the way that they are in the first place is beyond me.

  • All the views that you find expressed on here in postings and articles are mine alone and not those of any organisation with which I have any association, through work or otherwise. As regards editorial policy, whatever appears here is entirely of my own choice and not that of any other person or organisation.

  • Please note that everything you find here is copyrighted material. The content may be available to read without charge and without advertising but it is not to be reproduced without attribution. As it happens, a number of the images are sourced from stock libraries like iStockPhoto so they certainly are not for abstraction.

  • With regards to any comments left on the site, I expect them to be civil in tone of voice and reserve the right to reject any that are either inappropriate or irrelevant. Comment review is subject to automated processing as well as manual inspection but whatever is said is the sole responsibility of the individual contributor.