Restart Apache from the command prompt (Git Bash, CMD.EXE, batch file) on Windows 10, without receiving the "Do you want to allow this app to make changes to your device" prompt:

Or without the Access Denied message:

I won’t list all the things that don’t work. There are too many! Here’s how to do it:

First, you need to install Apache as Windows Service (note you must run the Xampp control panel as Administrator to be able to select this):

You then need to find out the service name for Apache. It’s probably Apache2.4 but click on Services, find it in the list and double check it.

Next you need to create a Windows batch file called restart-apache.bat, with the following contents (replacing Apache2.4 with the name of the service we just started):

net stop Apache2.4
net start Apache2.4

Don’t bother trying to run this batch file, it won’t work. Both commands will fail with the Access Denied message.

There are plenty of ‘solutions’ out there to make this work, including creating a shortcut to the batch file and setting run as Administrator in the properties. That sort of works, but you still get the "Do you want to allow this app to make changes to your device" prompt (minimized, requiring a mouse click to open).

So forget all of those solutions. Except for this one, that tells you how to avoid the UAC prompt using the Task Scheduler.

We won’t follow that exactly, but go through steps 1 to 6, setting up a task called Restart Apache, setting it to run with the highest privileges and configuring it for Windows 10.

Instead of entering %windir%\System32\cmd.exe as the action in step 7, just enter the path to the restart-apache.bat file we created above. There’s no need for any optional arguments in step 8.

Note: You can set it up to run the batch file using cmd.exe and start as per the article, but it doesn’t close after restarting Apache – running the batch file directly will close itself when done.

Keep going through the remaining steps to make sure it works when you’re laptop’s not plugged in and to create the shortcut to the scheduled task we just created. It’s probably sensible to save the shortcut in the same folder as the batch file so everything is kept together.

You obviously need to change the name of the service to the one we created above ("Restart Apache" unless you named it something different).

Click next and name the short cut restart-apache. You won’t be able to see it, but it’s extension is .lnk so we can access this shortcut via restart-apache.lnk.

You can test it out right now by double clicking on the shortcut:

There’s probably no need for steps 16 to 22. We don’t really need it to have an icon as we’ll be calling it via the command line anyway, rather than clicking on it.

Speaking of which, you run it from the command line using the following command (adding the path to the file name if you’re not in the same folder):

start "" "restart-apache.lnk"

That should work in CMD.EXE, a batch file, Git Bash, etc. I think the Windows Subsystem for Linux supports Start, but it seems like there are some hoops to jump through.

Anyway, that’s it! Go start using it in all your scripts!

So… Let’s just say for a moment, that you borked your plugin by accidentally tagging the whole repo. Never going to happen, right, because we all use deployment scripts, don’t we?

But let’s just suspend our belief for a moment. You’ve borked your plugin and instead of downloading it and testing it once it’s live, you go to bed. And while you’re having those sweet sweet dreams after a job seemingly well done, users have started updating. Only once they update, there is no your-plugin.php file any more, so the plugin promptly disables itself. You awake to urgent messages.

Hmm. You fix it and upload a working version, so they can just update it again. Nope. The plugin won’t appear in the plugins list any more.

Okay, they can just install it again from the Add Plugins screen. Nope. They’ll get an error telling them the plugin is already installed because the folder is already there, even though it doesn’t have a valid plugin inside it.

Defeat… Time for them to break out the old FTP client and upload the fixed version manually. Only this isn’t one user. This is everyone using your plugin. At least those who updated while it was broken. And some of these users aren’t exactly comfortable with FTP.

Of course. This is never going to happen, is it? But just say it did, perhaps it would be good to come up with a solution that would allow users to update the plugin via the backend.

Saving The Day

First, it must be said this is horribly hacky. And not without risk. Backups please! Perhaps it’s better not to even try this, or to only use it as a very last resort. But here’s what you may possibly decide to do – create instructions telling users to add the following to functions.php:

[sourcecode language=”php”]
function fix_your_plugin_add_steps() {
echo ‘<div class="updated"><p><strong>Fix the Your Plugin plugin:</strong><ul>’;
echo ‘<li>Step 1: <a href="’ . wp_nonce_url(self_admin_url( ‘update.php?action=upgrade-plugin&plugin=your-plugin/your-plugin.php’ ), ‘upgrade-plugin_your-plugin/your-plugin.php’ ) . ‘">Force Update</a></li>’;
echo ‘<li>Step 2: Choose the Activate Plugin link from the resulting page</li>’;
echo ‘<li>Step 3: <a href="’ . self_admin_url( ‘theme-editor.php?file=functions.php&scrollto=100000’ ) . ‘">Return to functions.php</a> and delete the code you added to create this list</li>’;
echo ‘</ul></p></div>’;
}
add_action( ‘admin_footer’, ‘fix_your_plugin_add_steps’ );

function fix_your_plugin_force_update( $transient ) {
$obj = new stdClass();
$obj -> slug = ‘your-plugin’;
$obj -> new_version = ‘1.0.3’;
$obj -> url = ‘https://wordpress.org/plugins/your-plugin/’;
$obj -> package = ‘https://downloads.wordpress.org/plugin/your-plugin.1.0.3.zip’;
$transient -> response[ ‘your-plugin/your-plugin.php’ ] = $obj;
return $transient;
}
add_filter ( ‘pre_set_site_transient_update_plugins’, ‘fix_your_plugin_force_update’ );
[/sourcecode]

It (almost) goes without saying that you should replace all instances of your-plugin, your_plugin and Your Plugin, with the equivalent for your plugin, as well as replacing the two instances of 1.0.3 with the new version you want to upgrade to.

The Instructions

As mentioned above, this is horribly, horribly hacky. You’d probably want to provide users with some decent instructions to follow, so as to limit the chance that this will just make their day (and yours) worse. Maybe something like this:

The safest way to fix this is to manually FTP into your server and delete the your-plugin folder and then re-install the plugin.

If you are not comfortable with doing this, I have another option for you. However, it requires editing functions.php and if you make a mistake you may break your site, so please be very careful. In fact, I recommend doing a site backup before trying this.

To use this work around, please go to Appearance, then Editor and locate Theme Functions (functions.php) in the long list of files on the right. Click on it and that file will open.

Double check that it says Theme Functions (functions.php) above the code editor area. If so, click in the code editor and scroll right to the very bottom (you probably won’t be able to see it at first until you scroll all the way down). Make sure the cursor is flashing and none of the existing code is highlighted.

Open the attached file containing the code to fix this and copy the code. Return to the code editor and paste the code, checking that it is exactly the same.

Then click Update Plugin. The page will refresh and a list will appear at the top of the page with 3 steps for you to follow:

1. Click the link in the first point to force the plugin to update itself to the latest version.
2. That will take you to a new page. Once the plugin has finished updating, you will be give a link to Activate Plugin. Click it.
3. That will take you back to the plugin screen. Click the link in the third point, which will take you back to editing functions.php, and remove the code we added above (taking care not to remove any other code).

If all has gone well, you should fixed the plugin, activated it and removed the temporary list of steps.

And of course you need to send them the code to go with this.

Interesting Bits

Whether this is a sensible thing to do or not, the code has some interesting stuff in there.

We are essentially mimicking what some premium plugins do – intercepting the call to the wordpress.org repository and adding our non-wordpress.org plugin to the list of plugins that WordPress has update information for. At this point, our plugin may as well be a non wordpress.org plugin, as the standard update mechanism is never going to allow our plugin to be updated.

We’re using the technique here, only instead of telling WordPress to download from our own server, we’re telling it to download from wordpress.org.

We do this by using the pre_set_site_transient_update_plugins filter to hook into the update_plugins transient and add our plugin back into the list of plugins WP is thinking about.

As well as this, we are adding a series of steps into a message at the top of every page in the admin area. These steps tell the user what they need to do to complete the process.

First, we link straight to the update link for the plugin. That won’t do anything without us hijacking the update_plugins transient. But with that other code block in place, WordPress will allow the update to proceed. Because it’s an update, not an installation, it won’t be put off by finding the folder in place. It will delete it (bye bye folder containing the entire plugin repo!), then install the plugin from .org (or whichever URL we added).

Next, we tell the user to Activate the plugin.

Finally, we need the user to get rid of the code added to functions.php. To help them do this, we provide a link to the Theme Editor, with the functions.php file open and the scroll to parameter set to 100000, which should place them at the bottom of the file (in all but the most extreme cases!), right where the code they need to remove is located. We need to make it easy for them, so that they actually remove it. Of course, the message will stay there forever unless they remove the code, which is a good incentive for them to remove it.

Final Thoughts

So, am I crazy? What would you do if you were in this situation: a) provide them the code above; b) tell them to use FTP; or c) something else?

Also, you should totally follow me on Twitter, so you can hear about more embarrassing stories that happen to, um, a friend of mine…

And it’s not just because it was the first time I got my name on a shirt either!

WordCamp Gold Coast T-shirt (source)

For me it was a turning point in my WordPress journey and 5 years on I decided to reflect on it’s importance to me.

Confession Time

Right from the moment I started using WordPress, I was building plugins and bending it to my will. I was far from a great developer, but I had a feeling that I could make WordPress do anything!

I only rarely met people locally who knew what WordPress was and their knowledge of WordPress was pretty limited.

The only people I knew who were good with WordPress were those I’d met online, who were all overseas. I’d heard of Dion Hulse, who’d been given core commit access, but it felt like there weren’t many WordPress developers in Australia.

Not only was I isolated, I had developed what can probably only be called Reverse Imposter Syndrome. I was overconfident in my WordPress skills and to be honest I came into WordCamp Gold Coast thinking I was sort of good. :O

Turning Point

Of course, WordCamp Gold Coast taught me that there were a load of great WordPress developers here, including people much cleverer than me. In fact, the Imposter Syndrome quickly reasserted itself and has steadily been growing worse since then!

While I could probably do without the Imposter Syndrome, it was a turning point for me. WordCamp Gold Coast let me realise that there was a passionate local WordPress community here, that I wasn’t alone, that there were others like me out there. And it was the start of many friendships for me.

I was no longer isolated, I’d found my WordPress family.

The Organisers

WordCamp Gold Coast was not only my first WordCamp, it was also my first time as a WordCamp Speaker, which was to become an important part of my self identity for a few years.

I guess I have that Reverse Imposter Syndrome to thank for giving me enough confidence to apply to talk! However, the people I really need to thanks are the organisors, all of whom were supportive, helpful and encouraging:

• Bronson Quick
• Lachlan McPherson
• Dion Hulse
• Brent Shepherd

I proposed several crazy ideas for talks and they basically said “No, what we really want you to talk about is WordPress and Government”. I’m so glad they did that, because in hindsight, that was an important talk and worked far better than the other topics I had in mind.

So, 5 years on, another shout out to the organisers: Thanks guys! I owe you so much.

Finding My WordPress Family

As well as the organisers, I met a bunch of other great people, all of whom I feel honoured to know: Dee Teal. Anthony Horton. Ryan McCue. Luke Carbis. Troy Dean. Brian Miyaji and AylaView from ThemeBoy. Dan Petrovic. Anthony Cole. Dan Milward (though I only met him that once).

And of course Japh Thomson, who told me a little about this company Envato that he worked for, starting me on the path to joining them myself years later.

I also got to meet John O Nolan, who doesn’t get a lot of love in the WordPress community these days, except from those who’ve actually met him. John gave a talk (sadly not recorded) that still ranks as the best I’ve heard. In return, we made sure John was educated on the dangers of drop bears and Yowies.

And so many others. I love the Australian WordPress community and this is where it all started for me.

A Funny Story

Well, this probably isn’t funny, but it tickles me..

During my talk, I mentioned a problem I’d been having working with the Twitter API. Someone tweeted me a solution while I was still talking. This person had a flying dog as a Twitter avatar and I didn’t immediately match it up to the young guy I met at the speakers dinner.

When I finally worked it out, at the after party I think, I told him he really should change his avatar to a photo so people could recognize him. I believe I may have preached that this was important for personal branding.

Of course he kept the flying dog avatar, which many in the WordPress Community would now recognise instantly, and totally proved me wrong in that regard. So much for my career as a branding expert!

Your First WordCamp Will Always Be Your Favourite

For me anyway! This little WordCamp (maybe 170 attendees) has a place in my heart that none other can replace.

I’ve been lucky enough to go to WordCamp San Francisco (the last one) and WordCamp US (the first one) and a couple of Pressnomics and a bunch of Australian WordCamps – and I’ve loved them all! Yet WordCamp Gold Coast will always be the one that is most special to me.

Of course, it wasn’t really the WordCamp itself that made it so special – it was meeting and becoming part of this WordPress Australia community that I love so much. The second half of my WordPress career has been so much more rewarding than the first half and it all started right there.

Final Thoughts

So that’s my story. I’m interested in hearing yours! What was your first WordCamp and how did it affect you? If you write about it, please feel free to leave a link in the comments below as I’d love to read it.

If you were hoping to get a reflection of what happened at WordCamp GoldCoast, instead of this sentimental stuff, check out Anthony Horton’s blog post from back in 2011.

*Photo blatantly ‘borrowed’ from Envato’s website

I’ve been really happy in my job and there have been many highs, including:

• Working for an awesome company. Envato has great values and it lives by them. I’ve seen big decisions made that were true to those values, rather than being best for the bottom line. Envato also does a lot around diversity and inclusiveness, both internally and externally and is just generally cool. I’m proud to work at Envato.
• Working with great people! Every single person I’ve met within the company is great and they are always willing to help out. It’s lead from the top – Collis is far more open, approachable and humble than any CEO has a right to be – and goes right through the company. I want to give a special mention to the ThemeForest and CodeCanyon reviewers, a super passionate bunch who I work with day in and day out. Their job is not an easy one and they don’t get much appreciation from anyone outside the company, but they put their heart and their soul into it.
• The job itself, which I love. I’ve been able to work on some truly challenging issues that impact a large portion of the Internet. I’m really appreciative of that opportunity. Also, I’m never, ever, bored. There always some new challenge being thrown at us.
• Being able to attend events overseas, which has without a doubt been an enormous highlight. I’ve been lucky enough to attend the last WordCamp San Francisco, the first WordCamp US and Pressnomics 3 & 4. That’s given me the chance to meet so many awesome people that I knew of online, but would never have met otherwise. Great people, great times!
• My work being more closely aligned with my passions, specifically WordPress, than my previous job. I do miss working on some of the other web disciplines (content strategy, SEO, analytics, usability, etc), but absolutely no regrets on this!
• Working from home, which has given me more flexibility to be there for my family. There is a trade-off in that I’m away some of the time, but all things considered, I’d make that trade-off any day. I’m actually far more present in their lives than when I used to catch the train to the city in the morning and get back just before their bed time.

Of course, there have been lows too:

• Large security issues. There have been others, but the Slider Revolution one was the first and wow, that was intense. There were a lot of challenges to work through in a short time and a lot of focus on us while we were doing it. In some ways, the experience of working on the problem was a positive: I like challenges and we had a great team working on it; but because of the effect it had on so many people, it has to be a huge negative. I will say the author, ThemePunch, were great to work with in very trying circumstances.
• The limited amount of change I’ve been able to affect. I came into Envato with a list of things I wanted to address and a load of ideas, but many of these never came to light. I hadn’t anticipated the volume of urgent and complex issues that come up as part of everyday business. These need to be dealt with, which takes attention away from the projects I’d like to see happen. I’ve had to be largely reactive, rather than proactive, in my role. The good news is that this has been recognised and there are plans to address this.
• Not being able to speak at or organise WordCamps. I spoke at the first three WordCamps I attended and it came to be an important part of my self-identity. Sadly, WordCamp rules prevent Envato employees from speaking at WordCamps, or organising them, even if all of their WordPress products are 100% GPL (as mine are). I won’t lie – that’s been hard to take at times. ;_;
• Side Projects: Unfortunately, most of my side projects have stalled or been severely limited. When I’m at my computer in the evening, I’m more likely to be tempted to work (because I enjoy it) or to keep up with what’s going on in the WordPress world (which has been an unofficial part of my job until James Giroux joined us earlier this year). I’m trying to change this and to spend more time on my side projects. Maybe I’ll even resurrect this blog. No promises on that though.

And there you go… I’ve probably missed some things, but all in all, I’m loving it and I’m looking forward to the next two years (or more!).

But…

When it comes to using the REST API with themes, it may not always be the best choice.

TLDR

If you’re building themes for your own site or for a large client with a dedicated web team, go knock yourself with all the coolness you can build with the REST API.

If you’re building themes that will be distributed or will be used by small to medium clients that don’t have dedicated support, then you need to ask yourself if using the REST API is really the best thing for your users. Chances are you’ll be making their lives harder.

Note: I’m not talking about standard themes that just use the REST API for Ajax requests. That’s fine. I’m talking about themes that do things radically differently.

Background

I’ve been writing this post for more than a year. It started off as a post about why using Twig/Timber in distributed WordPress themes may be problematic, but the same issues exist for the REST API too.

Given the relative exposure of each of these, I changed the topic to the REST API a few months ago. There are many posts coming out now covering all the thing that you can do with the REST API and almost none covering what you shouldn’t do. In these situations, bandwagons are jumped and people start using things just because they can, even when it may not be the best choice.

Listening to an episode of the Post Status podcast the other day was the final push for me to finish off this post. They were talking about Twig/Timber (and Genesis), but many of the same issues will apply to themes built with the REST API. In fact, I decided to widen the scope of this article to include custom themes built for a client, after listening to their discussion.

A Story

I’m going to pause for a moment and tell you a story.

I used to run government websites. When I started, things were done in a government centric way. The websites told people what the government wanted to say, not what people actually needed. There was loads of information about what government had done. Profiles of staff. That sort of thing. Have you ever had to use a site like this to get something done? Not easy.

In 2010, I joined a new team. One that was building a Whole of Government website that was, gasp, user centric! We researched what users actually needed and gave it to them! When people wanted to publish content that users didn’t care about, we could tell them no! It took a while for the business areas to get their head around why it was important, but eventually they worked out that the site was only successful if met the users’ needs.

The point? It’s never good to lose sight of what the users need or to start putting your own needs first. Just because you can build a theme with the REST API doesn’t mean you should. You need to ask whether it’s right for your users – in this case the site owners who use your theme on their website? Is using the REST API helping meet their needs – or hurting them?

Reality Check

The REST API is super exciting to most of us. Every second WordCamp talk is about it.* Every second episode of the Post Status podcast is about it.**
*this statistic may be made up
**actually I think this one is true!

But here’s the thing: The vast majority of users don’t care about the REST API. Yes, even when we are talking about site owners rather than site visitors. They care about their business needs being met.

If the REST API helps with that, they’ll be happy. If it gets in the way, they won’t be happy. Either way they won’t care about the REST API itself, just what it means for them in terms of meeting their business goals.

Meet Joan And Bob

Meet Joan. She owns a pest control company with 6 employees. She knows that having a website is crucial for the business, so several years ago she got a local web development shop to rebuild the site. She paid a lot of money ($8,000!) but was really happy with it, especially the custom theme they built. That company went out of business and she’s still looking for a replacement. She’s not in a rush. After all, WordPress is easy and neice can help her out.

Meet Bob. He just started a tutoring business on the side of his day job. He wanted a website, but doesn’t have much money to spend on it. He doesn’t know much about web development, but he knows his way around a computer, so he decided to go the ‘do it yourself’ route: he got a cheap Hostgator account, installed WordPress, downloaded a free theme from wordpress.org and set it up himself.

Joan and Bob have some things in common:

• They’ve both heard that having a blog, rather than just a brochure-ware site, can help get them more business – so they’ve both decided to blog daily!
• They both use themes that make heavy use of the REST API.
• Neither theme has one of those fancy author boxes at the bottom of the post. They both want one!

What did they do? They both googled "how to add author info in wordpress" and clicked the first result. That took them to a WPBeginner post telling them how to do it. Step 1: Add some CSS to style.css. A bit tricky, but they both managed it. Step 2: They just have to do the following:

open your single.php and add this code inside your loop.

Hang on… There is no loop. Maybe there isn’t even a single.php. Hmm, this WordPress thing isn’t as easy as people say…

Examples

Here are some examples of how Joan and Bob would go following those instructions with some real REST API themes:

• Jack Lenox’s Picard Present theme: There is no single.php.
• Chris Hutchinson’s REST + React version of Twenty Sixteen: There is no single.php.
• Human Made’s Feeling Restful theme: There is no single.php.

Game over…

Don’t get me wrong – these themes are great work that are pushing things foward! But they are not for Joan or Bob and we need to remember that.

A Cornerstone Of WordPress’ Success

One of the strengths of WordPress, which has helped get us to the 25% market share point, is that it’s so easy to tweak and to get help with. Not sure how to do something? Don’t worry. There are millions of ‘how to’ posts out there. Can’t get in contact with your old web developer? No worries. There are hundreds of thousands of developers out there who understand how WordPress works.

Community support is a cornerstone of WordPress’ popularity. However, that’s built on things being done in a fairly standard way. As we enter the exciting new world, some of that will be eroded.

For users with a non traditional theme, many of those tutorials won’t work and they may need to get a more experienced developer to help them. Help will still be there, but it won’t be quite as accessible. For some users, this won’t be a problem. For many others, it will be.

We need to remember to design for the majority. Most WordPress users don’t know or care about the REST API. Many don’t have enough money to pay experienced developers to look after their site. Many will try to tweak the theme themselves at some point.

Using The REST API In Themes

I’m not saying "never use the REST API in WordPress themes". If there is a genuine need, then by all means use it! Just use it appropriately, keeping your users in mind.

If you do use it, then make sure you clearly communicate that with your users. If you’re developing themes for WordPress.org or a marketplace, make sure your documentation explains to users what they should expect. Try to keep the structure fairly standard and provide good comments in your code (or get ready for those support requests!). If you’re developing a custom theme for a client who may one day change to a different developer, do the same.

Both WordPress.org and marketplaces should consider how they make it clear to buyers what they are getting (ie flag to users that REST API themes are somewhat different). Neither wants to promote confusion. Marketplaces also have refunds to consider. There will always be power users who will understand what they are getting and need that – but that’s not the majority.

Final Thoughts

It’s straightforward really. Put your users’ needs first. Use the REST API when it’s appropriate. Don’t just use it because it’s cool! Maybe this is just common sense, but it needs to be said.

Do you agree? Disagree? Did I miss something? Let me know in the comments.

In this post, I’m looking at the last of those scenarios. What should theme authors do now that WordPress itself offers the equivalent functionality?

What Theme Authors Should Do

If you’re a theme author, you should probably start planning to remove your theme’s favicon code. There’s no point duplicating what is now in WordPress core, unless you are extending it in some way, and this is probably one of those things that doesn’t have a lot of scope for extension.

Also, note this from the Site Icons announcement post:

Site Icons work out of the box, are theme independent, and don’t require theme support.

That means that if a user goes into the Customizer and adds a site icon, it’s code is going to be added to the source, right next to your favicon code. It’ll look like this (the first 4 lines of favicon code come from core, the last 2 come from the theme):

Both the core site icon code and the theme’s favicon code appear in the source

Not good! So you should be removing your favicon code. However, I think it makes sense for this to be done in a backwards compatible manner.

Backwards Compatibility

Rather than just ripping your theme’s favicon right out of the theme, you should probably keep it for users who can’t yet use site icons. There are two parts to this:

1. Allowing a user to add a favicon via theme options
2. Outputting the code for the favicon to the page

Ideally we want to allow both of these for versions of WordPress prior to 4.3.

For users on 4.3, we want to restrict the use of number 1, getting them to add their favicon via site icons instead. However for number 2, we should probably keep outputting the favicon code until the user sets up a site icon (more on this later).

Input – Adding A Favicon Via Theme Options

Some of your users are probably not on WordPress 4.3 yet and won’t be able to use the site icons feature. To provide those users with your favicon theme option, but to prevent users on 4.3 from using it, you’d do something like this:

[sourcecode language=”php”]
// if the `wp_site_icon` function does not exist (ie we’re on < WP 4.3)
if ( ! function_exists( ‘wp_site_icon’ ) ) {
// show the user your favicon theme option
}
else {
// display a message advising the user to use the site icon feature
}
[/sourcecode]

This shows the theme’s favicon option to users who are on versions of WordPress older than 4.3. Users who are on WordPress 4.3 or above will be told to use the site icon feature. The message telling the user to user the site icon feature is a nicety to be sure. You could leave the else statement out and just not display anything (but you may get more support requests that way).

Output – Adding Favicon Code To The Source

Right, we’ve stopped people using your theme’s favicon option when they have the core site icon feature available. Now we need to control the output of your theme’s favicon code.

There’s a temptation to use the same if statement as above, checking for the existence of wp_site_icon, but there is a problem with this. This only checks whether the user is on WordPress 4.3 or above, it doesn’t check whether the user has actually set up the site icon.

If they haven’t then WordPress won’t be outputting any favicon code. By wrapping your favicon code in if ( ! function_exists( 'wp_site_icon' ) ), your theme won’t be outputting any favicon code either.

End result: The site icon will be added to the page if it exists, but the theme’s favicon code will only be output on versions prior to 4.3. Users on 4.3 without the site icon set will have no favicon code on the page at all.

Neither the core site icon code or the theme’s favicon code appear in the source

The problem? Users will update to WordPress 4.3 and all of a sudden their favicon will disappear. Many will not realise that they need to re-add their favicon as a site icon. Bad for the user, bad for the length of your support queue.

Fortunately WordPress 4.3 gives us the has_site_icon function, which tells us whether a site icon has been set up or not. So we can use this code instead:

[sourcecode language=”php”]// If the `has_site_icon` function doesn’t exist (ie we’re on < WP 4.3) or if the site icon has not been set
if ( ! ( function_exists( ‘has_site_icon’ ) && has_site_icon() ) ) {
// output your theme favicon code to the page source
}
[/sourcecode]

This outputs the theme’s favicon code only if the user has not set a site icon (or if they are on versions of WordPress older than 4.3). If they have set a site icon, then the theme’s favicon code will not be included in the page, so there will be no duplication.

Now only the theme’s favicon code appears

End result: There will always be one set of favicon code on the page. Priority will be given to the core site icon if it’s set, falling back to the theme’s favicon code if necessary.

What Theme Authors Shouldn’t Do

It is possible to remove the Site Icon section from the Customizer. I strongly recommend you don’t do that. This feature will be standard across all WordPress installations and removing it will only confuse people.

Final Thoughts

Now that site icons are in core, themes should be phasing out their favicon functionality. By using the code above to provide backwards compatibility, we can ensure that end users have a smooth transition from the old method to the new, without their favicon being lost.

There may be an alternative point of view that we should just let things break, as that will drive awareness and adoption of the new core feature (and encourage people to update). There will also be those who say, it’s just a favicon!

Both are right to a degree, but personally I think backwards compatibility is more important. What do you think?

Note: Credit goes to Kailoon Chan who had a long discussion with me about this, helping me polish these ideas.

Instead this post is about a guy called Jeff Chandler, a website called WP Tavern and a podcast called WP Weekly.

I learnt of Kim’s passing through the tweets of Jeff who’d been at the centre of this sad story (at least at the very end of it). Upon reflection, I realised that I first came across Kim back in 2009 when she was on the WP Weekly podcast, created and hosted by Jeff. She appeared on a number of episodes and came across as very knowledgeable and likeable. And I got to know who she was because of Jeff (and her willingness to step up and get involved).

Further reflection lead me to realise that Jeff, the Tavern and WP Weekly have been at the centre of an awful lot of what’s gone on in the community over the years. The big stories and the little. Too many to name.

I’ve been a part of the WordPress community for a while now. Not a big part admittedly, but I’ve been sitting in my little corner since 2007. And in that time, I’ve learnt more about what’s going on in the community through Jeff than any one else. Yes he’s taken the odd hiatus or two, but for the most part he’s been there throughout, putting himself into the community with heart, body and soul.

The community has grown and there’s a lot happening in spaces around the edges, so its hard for anyone to be across everything, but for me, Jeff is still at the centre of it all. I still learn more about what’s going on from him than anyone else. I’ve always appreciated that, but today I appreciate it more than ever.

Jeff, this one’s for you. At the moment, the focus is on Kim and rightly so, but it’s also time to give you a shout out. Thanks for being there over the years at the centre of the community. You’ve obviously been through a lot in the last couple of days, but please know that you mean a lot to many of us in the community. Thanks Jeff.

Recently, there has been some discussion around whether Jetpack is bloated. Hmm, actually, we’ve been talking about that for years… Anyway, the interesting part to me isn’t whether Jetpack is bloated, it’s why Jetpack is bloated.

Disclaimers

I need to point out that these are my opinions, formed over many years, and are in no way endorsed by the company I work for (Envato). That’s always the case with this site, but I’ll make it extra clear for this post.

I’ll also clarify upfront that this is just about Jetpack. I like Matt Mullenweg and Automattic and are grateful for the amount of effort they put into the project and the community. I like the people who work at Automattic. I think a lot of the features included in Jetpack are brilliant. But personally, I don’t like the philosophy behind putting all these features in one plugin.

It’s not good when you have to start a post with a bunch of disclaimers like that, but I really don’t want people to take this the wrong way! In fact, I almost didn’t publish this.

The Discussion

A few weeks ago, Eric Mann wrote an article titled Bundling and Bloatware, where he essentially argues that Jetpack is bloated. There is a great debate in the comments, including a passionate defence (yes it comes across as a defence) from some of the Jetpack team. Set aside half an hour and go read it all.

Not long afterwards, Sam Hotchkiss wrote up some tests showing Jetpack is actually faster than using other plugins to do the same jobs. Matt Mullenweg then briefly wrote about it, linking to Sam’s post. Interesting comments in both those places as well.

So Is It Bloated Or Not?

In my opinion, yes. I have no doubt it is very well coded and it’s been proven not to be slow, but in terms of features, its, well … bloated.

I’ll concede that it’s better to have a well coded, bloated product than a poorly coded, minimalistic product. It’s important to note that there are some very good developers in the Jetpack team and I have no doubt the code is solid. Still…

Philosophically, I prefer products that try to solve a single problem really well. I don’t like products that try to solve many, unrelated problems. I think it would be better for Jetpack to be a series of plugins, allowing people to only install the ones they need.

The WordPress Philosophy

From the Clean, Lean, and Mean section of the WordPress Philosophy:

We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.

If you were to judge Jetpack by that statement, you would have to say they’ve ‘blown it’. I understand that was written for core and doesn’t have to be followed for a plugin, but it seems the philosophy adopted by Jetpack is diametrically opposed to the WordPress Philosophy. Personally, I think we should all follow the WordPress philosophy as closely possible.

In the comments of Eric’s post, George Stephanis, the Jetpack lead, says:

If you disable a feature, the code isn’t included. It isn’t loaded. It isn’t run. How is that harming you in any way?

But if that’s true, then why do we try to keep stuff out of core? Why bother? Lets add a basic contact form to core, let’s add custom CSS, Markdown support, XML sitemaps etc. They don’t harm anybody if they are disabled, so lets add them! To be clear, I’m not actually suggesting we do this. I’m just highlighting the philosophical disconnect between Jetpack and WordPress itself.

Hang On, Aren’t You The ThemeForest Guy?

Yep. And yes, there are themes for sale on ThemeForest that are bloated. I don’t like those either. Would I like them to trim down? Yes! Am I holding my breath? No. Just like I’m not holding my breath for Jetpack to start stripping features out.

I regularly get into discussions around theme bloat and I always argue that themes should keep things simple, rather than including loads of features. There are a variety of arguments I use, one of which is encouraging people to follow the WordPress Philosophy in their products.

Occasionally I get the push-back: “Well Automattic don’t follow it with Jetpack, why should we”? It’s deflating to have that thrown at you. It’s hard to tell someone they shouldn’t add lots of features into a theme when Automattic is busy adding lots of features into a plugin.

Note, this is purely about features, not code quality or best practice. We don’t want functionality in themes either. If a theme must have a load of features, then it should be through integrations with plugins, etc.

Why Is Jetpack Bloated?

So far, I’ve just rehashed the same old discussion about whether Jetpack is bloated. I’m sure that will just result in the same arguments for and against, so let move on to the main point of this article: to answer why Jetpack is bloated.

Whenever you listen to Matt, or George or Jeremy Herve talk about why Jetpack has so many features, they always say they are doing this to help the users. To quote Jeremy:

your life is still way easier when you don’t have to worry about 30 plugins, because one plugin comes bundled with everything you need to get started. That’s what some of the people I help every day like about Jetpack.

Interestingly, that is very similar to what theme authors say: that their research shows that end users just want to install a theme that comes bundled with everything they need, they don’t want to have to find and install a bunch of other plugins.

In both cases, people are saying it’s for the end user. I do think they genuinely believe that. And I agree that’s what end users want (although personally I think that’s not what’s best for them). But there is more to this equation than that – there is also a business element.

The Business Case For Bloat

The bottom line: The more value you provide, the more likely it is that someone will use your product.

Users often conflate value and features, so simply adding more features make it more likely they will use your product. They don’t even have to be particularly useful features (though Jetpack’s are). Oh, having a good product is important, as is good support, etc, but (sadly) great marketing of features will take you a long way.

For theme authors, having more features means that more people will buy their theme, which equals more $.

Jetpack follows a different business model – it’s free but with up-sells on premium features. I’m guessing we’ll see more and more commercial elements in Jetpack in the future. Regardless, the economics are the same: the more features in Jetpack, the more people will use it, which equals more $.

Why is Jetpack so important to Automattic? This is purely supposition, but wordpress.org users represent a huge market and presumably Automattic want access to that market. They can’t do that through core. The next best thing is a plugin – but how do they get everyone to download it? Providing lots of value – and lots of features.

If Automattic had released Jetpack as 33 different plugins, as much as that would have made me happy, it would not have given them the leverage or user base that a mega-plugin gives them. Although I personally don’t like the bloat, I can see that it makes a lot of sense from a business perspective.

None Of This Is New

The thing is, what I’m saying isn’t new. Remember WPCandy? Well they said a lot of this almost 4 years ago, not long after JetPack launched:

I don’t mean to downplay what the Automattic folks have been saying about wanting to bring .com features to .org users. I believe they want that too; their altruism is, I believe, honest. But there is a very strong business component to this decision as well.

I think Ryan nailed it way back then. Automattic are trying to improve the world with Jetpack, but there are also some important business drivers with it as well.

Final Thoughts

This debate is not going away any time soon. Those people who think Jetpack is bloated aren’t going to be convinced by any of the arguments to the contrary and Jetpack’s not going to start trimming down its feature set.

When arguing about this however, it’s important we understand that it’s not really about philosophy or best practice – it’s about business. And Jetpack is here to stay.

Yesterday, it was announced that there was a critical security vulnerability with versions 3.0 to 3.9.2 of WordPress.

You can read more about what you should do on the Envato Market Blog and full details of the vulnerability are given on Jouko Pynnonen’s website (Jouku discovered the issue).

In a nutshell, the vulnerability allows an attacker to inject JavaScript into a post just by leaving a comment (although the JavaScript has to be formatted in a certain way). That JavaScript code will then be executed on any subsequent page load containing that comment, both on the front end and in the comment moderation queue in the back end.

Here’s a video showing how easy it is to exploit the vulnerability:

In the video, I just redirected the page to Google’s home page. Any vistor trying to access that page is going to end up at Google. I could have done stuff that’s a whole lot worse than that, but that’s bad enough…

Now, this didn’t affect verison 4.0 (although there were some other fixes for that). Websites using 3.9.*, 3.8.* and 3.7.* should have been updated automatically to a secure version by now (asuming automatic updates are turned on). However, versions 3.0 to 3.6.1 are unsupported, so there is no update for those versions.

Well that’s not so bad you’re thinking. Can’t be many people using those old versions.

Wrong. A series of tweets from Rarst lead me to have a good look at the stats page on WordPress.org. This is what it shows:

Look at it. Now look at it again. Right… so more than half the WordPress sites out there are on 3.6 or older. More than half of all existing WordPress sites are vulnerable. That’s roughly 12% of the web. I said this was really serious.

This just goes to show how important the Automatic Update functionality is. I was originally a skeptic, but I now consider it one of the most important features ever added to WordPress. Thanks to the devs who did the hard work to implement it (looking at you Dion)!

Unfortunately, there are still a bucket load of sites out there just waiting to be exploited. We can’t have more than half of all WordPress sites just sitting out there as timebombs. I don’t think this is one we can let pass quietly. We need to spread the word and get people to update their old sites. Everyone should be on 4.0.1.

If you have any old sites out there, make sure they are updated! If you have clients or friends who might have old sites, get them to update!

Does anyone out there have any contacts at Google? They send out emails to Webmaster Tools users telling them to update WordPress. Perahaps they could send a special email given how serious this and how widespread this is.

Does anyone have any other ideas?

It showcases your plugins on your WordPress blog, using the WordPress.org plugin repository as a source. It generates both a directory listing page, and the content of each plugin’s page. All you have to provide is the title; the rest comes from the repository. You get to control the markup of each type of page using intuitive WordPress shortcodes.

I recently decided not to have out of date plugin pages, so I made the switch to I Make Plugins. It’s straight forward to set up, but I needed to tweak a few things to improve the user experience. They’re listed below, just in case they are of use to anyone (or I need them again!).

Swapping Links To The Current Page

First a screenshot:

Page on my site created using I Make Plugins by Mark Jaquith

Notice the link in the paragraph? Along with the rest of the content, this is pulled in from the readme.txt in the Directory. It links to the plug home page on my site. Wait, that’d be the same page that the screenshot was taken on. It’s linking to itself!

That’s not the end of the world, but it could be confusing to users. I’d much rather it link to the WordPress Directory page. Fortunately, that’s pretty straight forward to do. Simply add the following code to functions.php or a functionality plugin:

[sourcecode language=”php”]
function scratch99_i_make_plugins( $content ) {
global $post;
return str_replace( get_permalink(), ‘http://wordpress.org/plugins/’ . $post->post_name, $content );
}
add_filter( ‘cws_imp_plugin_body’, ‘scratch99_i_make_plugins’ );
[/sourcecode]

The cws_imp_plugin_body filter allows us to target the content of the page after I Make Plugins has created it. It calls a function where we attempt to replace any links to the current page with a link to the Directory page.

In that function, we use get_permalink() as the string to search for. That will search for the full URL, which is exactly what we want. It will only find exact matches, it won’t find other (lower level) URLs starting with the URL of this page.

If it finds any matching links in $content, it replaces them with the link to the WordPress Directory URL and returns the result. The WordPress Directory URL is built by adding the post_name field for this page to http://wordpress.org/plugins/. Because I Make Plugins matches the readme.txt file based on the same field, this should always work (unless wordpress.org change their URL structure).

If no matching links are found, it will return $content unchanged.

And that’s it. The link in the screenshot above has changed from http://scratch99.com/products/fix-duplicates/ to http://wordpress.org/plugins/fix-duplicates.

Adding ID Attributes To Elements

I need to be able to link directly to certain parts of the plugin home page, using the id attribute. For example, I want to be able to link straight to the Support section by adding #support to the end of the URL for the plugin home page.

That’s not in the HTML created by I Make Plugins, but once again this is easy to do. I’ve extended the code above to achieve this:

[sourcecode language=”php”]
function scratch99_i_make_plugins( $content ) {
global $post;
$content = str_replace( get_permalink(), ‘http://wordpress.org/plugins/’ . $post->post_name, $content );
$content = str_replace( ‘<h4>Support</h4>’, ‘<h4 id="support">Support</h4>’, $content );
return $content;
}
add_filter( ‘cws_imp_plugin_body’, ‘scratch99_i_make_plugins’ );
[/sourcecode]

We’re now manipulating the $content variable over a couple of lines before returning it. Line 3 is essentially the same as above. Line 4 searches for the particular HTML string you’re targeting (in this case '<h4>Support</h4>') and then replaces it with the altered string with the id attribute added. Obviously you need to know the exact HTML that will be in the page, but this should be easy to predict given you are creating the readme.txt file.

Note: If anyone is wondering how I added the plugin submenu shown in the screenshot, I simply filtered the_content and pre-pended it to the front. But that’s a story for another day…

That’s just a couple of examples of how the output of I Make Plugins can be tweaked. You can take the same approach to do a whole lot more. Let me know what you do.