Tips and Tricks on WordPress usage and development. I am very passionate about WordPress, but it doesn’t work just by itself – it needs a rich environment to live and breathe in.
If you’re after theme and plugin alterations, we have a category for that.
If you’ve ever tried to upload an ebook in .MOBI or .EPUB format with the WordPress Media Uploader, you will have noticed an error message appear. Something along the lines of “Sorry, this file type is not permitted for security reasons”.
The only way then appears to be to ZIP the file and share it. That’s not a great experience for mobile users, who would simply like to click on a file and open it in an application such as iBooks or Kindle.
The solution to this puzzle lies in adding the required mime types to WordPress, so that these file types are allowed.
Front page posting is what the P2 theme is all about – but I personally find the default font size on the front page a bit too small. Perhaps it’s my raging tired eyes. In every child theme I write for P2, I usually increase this – both for immediate posting, as well as for text editing (which also happens inline on the front page).
To do that, add the following to your style.css file:
1
2
3
4
/* larger text for post box and editing */
#postbox textarea #posttext, textarea.posttext {
font-size:1.3em!important;
}
This will address the font size for both inline editing as well as posting. I’ve chosen 1.3em because it integrates well into my other settings, but feel free to choose something larger or smaller (1.2em or 1.4em respectively). You can also choose a defined point size like 16px if you like.
To also address the text box for default comments, we can add this:
1
2
3
4
#respond textarea, .textedit textarea {
font-size:1.3em!important;
color:#555;
}
By default the font colour is black, so #555 tweaks it to be the dark grey that the rest of the P2 text has.
Last week I found some time to update my fork of Automattic’s P2 theme, aptly titled P2 Categories. In addition to all the greatness of P2, it’s been adding front-page category posting since 2013 (and hasn’t seen an update since then either).
Here’s what’s new in the latest version:
fixed the drop down menu, which was no longer working since Safari 10
rewrote the whole theme from scratch, based on P2 v1.5.8 (2016)
fixed a bug that would not show the correct number of posts in a category
added new p2-categories-functions.php file
updated a call to a deprecated WordPress function with wp_get_current_user()
fixed several PHP 7 deprecation warnings
updated class constructors to use __construct() methods
hunted down undocumented features and documented them
added a changelog file
P2 is no longer maintained by Automattic, except for dire security patches. I’ve noticed several deprecation notices, both for WordPesss 4.9 as well as PHP 7.2.1 and fixed those as well.
Get the latest version on GitHub
You can download the latest version of the theme over on the official GitHub Repository. Feel free to examine the code, tinker with amendmends and share with everyone who wants to use P2 with categories:
I had submitted previous versions of P2 Categories to the WordPress repos too, and you can still download version 1.5 there. However, since 2013 web standards have become more strict, and there’s no way my theme would pass modern tests the theme team are using for new submissions. Sadly I’m not a web developer and it’ll be very difficult for me to update aspects of the theme I don’t fully understand.
Having said that, if you know how to pass modern web standard tests, feel free to send me a pull request on GitHub.
By default, Automattic’s phenomenal P2 theme does not support posting into categories from the front page, it only supports tags. My fork of the theme called P2 Categories does that though and lets you conveniently select a category from a drop down menu right there on the front page.
I wrote an update to it last week, and in so doing my article from 2013 came in handy that explains how to add this functionality to P2. Nothing much has changed in the source code, so it’s still relevant and accurate.
What the above article did not explain however was how to show which category a post belongs to. And because it’s still fresh in my memory how to do this, I thought I’d better write it down for next time (and anyone who’s interested in how to do it).
Most of my own WordPress sites have been up for longer than a decade at the time of writing, and I was wondering how much I had written in that time.
Post count notwithstanding, I was interested in the total word count of my output in that period of time.
Here’s a small function that retrieves just that.
Word Count in Posts
Comments
But word count from posts is not all that a website adds up to: I have answered several thousand comments since then, and my answers may fill a whole book just by itself.
Here’s how to retrieve the comment word count for the current user:
To retrieve the total word count in all comments instead, we can do much the same thing by leaving out the user_id parameter in the above query. Subtracting the total word count from the current user word count would then reveal the comment word count that everybody else has left on a site.
WordPress has a hook that lets us add arbitrary HTML code to the <header> tag of a website. Several plugins can be found that accomplish this, but it’s so easy to do that a plugin is often overkill.
Here’s how you can execute an arbitrary PHP function using the wp_head hook:
1
2
3
4
5
// write some text as part of the header
function writeSomeText(){
echo'Hello from my new header function.';
}
add_action('wp_head','writeSomeText');
This example inserts some text into the <header> portion of the website. HTML tags can simply be written using echo, including double quotes.
There’s a handy function in WordPress called wp_get_archives(). With it we can create a lot of useful output with just a few lines of code.
To list all articles ever published on a site, we can do this:
Here we setup a list of arguments and then give it to the function, which in turn gives us a nicely formatted list of every published article.
If we set the show_post_count argument to true, and replace the type argument to something like “yearly” or “monthly”, we’ll get clickable a list similar to this:
April 2015 (20)
March 2015 (11)
February 2015 (2)
January 2015 (7)
December 2014 (4)
November 2014 (12)
The number in brackets shows up when the show_post_count argument is set to true instead of false.
We can even find out how many articles have been published on the entire site by using the wp_count_posts() function. Here’s how to use it:
1
$totalPosts=wp_count_posts()->publish;
$totalPosts now holds the amount published posts. We can also query drafts or posts of any particular post type too if we wanted to (such as all status updates or video posts).
I really like WordPress, and I really like JetPack. I use the plugin on many client websites, who usually have their own WordPress.com account, which is necessary to enable the plugin successfully.
Most of them however choose not to sign up for a payment plan, which as of 2017 leads to (now rather annoyingly frequent) JetPack upsell messages at the top of the admin screen. So I as the administrator, am constantly exposed to such messages, and I was wondering how to suppress them – not being the target audience here.
I had a weird phenomenon on a Multisite installation the other day. I can’t tell you with which update exactly it happened, as I only write a post on that site once every couple of months, but it must have been around the 4.7 or 4.8 upgrade. Here’s what was happening:
I could log into the site fine, I could display all posts in the backend fine, but editing them, or creating a new post (or page) resulted in an unresponsive editor window. Neither the Visual Editor nor the standard Text Editor wanted to accept any keyboard input. Moreover, none of the buttons could be pressed, including the Publish button.
The rest of the admin interface looked and behaved completely normal. I could even write posts from the iOS app, so fundamentally the installation wasn’t broken, just the editor part of it. Made no sense to me at all.
Things I’ve tried
I tried the usual tricks for getting rid of such a spurious affair:
re-install WordPress manually
disable all plugins
use a different default theme (in fact, I’ve tried several)
try logging in as a different user
since this was multisite, try writing a post on another site (same issues there)
since this was an installation managed from Plesk via the WP Toolkit, try more lax security settings
I probably tried other things, but none of it was making that editor working again. I didn’t understand what was going on.
The Solution
The solution came after extensive research, one part of which lead me to this thread in which Peter Luit explained a related problem that he could fix by defining a constant in the wp-confg.php file. I had never heard of it either:
1
define('CONCATENATE_SCRIPTS',false);
Turns out that this constant is enabled by default and means that all JavaScript files are loaded with a single call, rather than multiple calls to multiple files. The idea is that, if your site is healthy, and every single JavaScript file is working fine, all of them together will execute and work fine too. However, should one in the middle not work so well, then the rest of them won’t be executing, and I guess that’s what happened on my installation.
By setting this constant to false, each JavaScript file is loaded individually, resulting in more http requests to the server (potentially making the overall load time slower), but every JavaScript file can be executed individually. If one isn’t working, none of the others are impacted. Hence, now my editor is working again, however I still have at least one JavaScript file that has an issue executing. Finding which one would be the next step.
So this constant isn’t a “fix” as such, it’s part of a debug strategy. But it’s great to have my site back up and running so I can continue to write posts.
Most of my own WordPress sites have been up for longer than a decade at the time of writing, and I was wondering how much I had written in that time.
I really like WordPress, and I really like JetPack. I use the plugin on many client websites, who usually have their own WordPress.com account, which is necessary to enable the plugin successfully.