Author: Ipstenu (Mika Epstein)

Switching The Main Blog on Multisite
Previously I’d only ever posted this in my ebook, WordPress Multisite 110.

What people mean by this is the site they originally set to be seen at domain.com is no longer the one they want to use, but the one at (say) domain.com/temp or temp.domain.com. If this is what you’re wanting to due, it’s not impossible, but it is annoying and a little tricky. If you’re using the trick to give WP it’s own directory, these are not the directions you’re looking for. I haven’t written those out yet.

First you have to go to Network Dashboard > Sites and edit the site you want to be the main site.

This you want to to look like this:

~~Make certain you leave ‘Update siteurl and home as well’ checked! If you forget that, you’ll be sad.~~ You no longer need to check the box (it’s gone in newer versions of WP), but if you DO have it, check it.

Now you’d think you go to edit the main site and change it, but you can’t.

By default, the main site is not editable. This makes sense when you think about how messy this might be, so in order to edit it you have to go to your wp-config.php file and look for this line:

define('BLOG_ID_CURRENT_SITE', 1);

Change it to the site ID you want to use as your main site. In this example, I want site #2, aka, two, to become my main site.

define('BLOG_ID_CURRENT_SITE', 2);

Save the file and then you have to go back to your Sites and edit the old main site.

Give its path a new name and press save, making sure you keep that checkbox checked if it’s there.

In this example, I’ve picked a new URL for my formerly main site becuase I don’t want any conflicts, but there’s nothing stopping me from picking ‘two’ again and just totally swapping things.

The last step is to change your post content. Using a plugin like Velvet Blues Update URLs, you will need to search each site separately and replace the URLs. If you have wp-cli, you can do that too like this:
```
wp search-replace 'example.com' 'example.com/new' wp_posts wp_postmeta --dry-run
wp search-replace 'example.com/two' 'example.com' wp_2_posts wp_2_postmeta --dry-run
```
If those look good, rerun without dry run and call it a day!

An interesting quirk is that you may need to edit the Fileupload URL if you’re using blogs.dir for your images. I noticed that on one site it was set to http://example/two/files which clearly is wrong. To fix that, go to Network Admin, click on Sites, and click on edit for the site. From there, click on the dangerous “Settings” tab and look for “Fileupload URL” and edit as needed to match things.

Cool tricks like this can be found in WordPress Multisite 110.
3 December, 2014
Being Smart Cures Headaches
While reviewing WordPress plugins, I often kick a plugin for calling file locations poorly. This usually happens when they’ve hardcoded their plugin name or (worse) wp-content into paths.

When you hardcode in paths, or assume that everyone has WordPress in the root of their domain, you cause anyone using ‘Giving WordPress it’s own directory’ (a VERY common setup) to break. In addition, WordPress allows users to change the name of wp-content, so you would break anyone who choses to do so. And when this happens, I always link them to how to figure out the constants, which leads them to the function plugins_url().

In many ways, plugins_url() is a panacea, a silver bullet, because it can take this:
```
<?php
echo '<img src="' . plugins_url( 'images/wordpress.png', __FILE__ ) . '" > ';
```
And magically turn it into this:
```
<img src="http://www.example.com/wp-content/plugins/my-plugin/images/wordpress.png">
```
Even better, if you put the plugin in the mu-plugins folder, it would know to be this:
```
<img src="http://www.example.com/wp-content/mu-plugins/images/wordpress.png">
```
That makes it insanely flexible and wonderful.

This allows me to happily rename a plugin folder to my-plugins_off to force disable it and will reward me with this error:

I like that error. I like that it happens no matter what, once I’ve renamed that plugin folder and I refresh a page that uses the plugin, it’s gone. Of course, sometimes it’s not enough, but most of the time, if you know what plugin’s being a doofus, you can fix it with that.
1 December, 2014
Don’t Reinvent the Wheel
In WordPress, I punt plugins now and then for doing weird things that can best be described as reinventing the wheel.

Any time a plugin replicates functionality found in WordPress (i.e. the uploader, jquery), it is frowned upon. It presents a possible security risk since the features in WordPress have been tested by many more people than use most plugins. Simply put, the built in tools are less likely to have issues.

This was always something a little theoretical. I hadn’t yet run into someone who had broken their code with an upgrade of WordPress just because we updated the core wheel. Until November 20th.

The shortcode API in WordPress was updated. It was decided that in order to stop breaking on PHP 5.4.8 and under, we needed to apply wptexturize() to shortcodes. This had a fun side effect when people didn’t properly register shortcodes, which of course brought up the logical question … why wouldn’t you register your shortcode?

What I generally see in plugins is someone’s using a filter to look for their shortcode instead of registering it, so the post content is, in it’s entirety, parsed. That always struck me as foolish, since posts can get pretty long if Chris Lema or I are writing. And the reason people would do it was also odd. Either they were being lazy, they didn’t know about shortcodes (which I can understand, you can’t know everything), or they were trying to get around an ‘issue’ with nested shortcodes.

For what it’s worth, the shortcode parser correctly deals with nested shortcode macros.
```
[tag-a]
   [tag-b]
      [tag-c]
   [/tag-b]
[/tag-a]
```
That works fine. This won’t:
```
[tag-a]
   [tag-a]
   [/tag-a]
[/tag-a]
```
Now I want to note, I’m using a php shortcode around those tags. So yes, it works great. But the problem would be if I wanted to show you the php code in a php shortcode… Doesn’t work that way, and it’s a limitation of the context-free regexp parser used by do_shortcode(). We went for speed over levels, and it can’t match each opening tag with its correct closing tag.

Obviously the ‘right’ answer is ‘don’t nest same-named shortcodes’ but instead, some plugin authors have chosen the strategy of not registering shortcode names. That way the parser doesn’t try to mess with it. Sounds great, right?

Not with wptexturize() running.
```
[tag-a unit="north"]
   [tag-b size="24"]
      [tag-c color="red"]
   [/tag-b]
[/tag-a]
```
That turns into this:
```
[tag-a unit="north"]
   [tag-b size=&#8221;24&#8221;]
      [tag-c color=&#8221;red&#8221;]
   [/tag-b]
[/tag-a]
```
Basically the code is understood to be code and not a quote. That means it would simply output the tags as code and not the tag content.

And you see why this is a problem.

There are two answers to fix this. One is to turn off wptexturize for your pseudo-shortcodes (via the no_texturize_shortcodes filters which are not complete, sadly, if you need to unfilter shortcode variables) and the other is to use the Shortcode API as it was intended. I would, personally, suggest you use the API since that prevents your code from breaking like this if another security update happens.

Which brings us back to why reinventing the wheel is generally foolhardy in robust, well maintained systems. WordPress is constantly being improved, fixed, patched, and secured. The more you work around it by making your own way, the harder it is to fix things when WordPress makes a change. You’d think that people who make their own wheel would be attentive to anything that might break it, but they rarely are. They make their way, forget about it, and get annoyed when their code breaks and blame WordPress for not warning them. That’s a dirty secret about Open Source. No one’s going to tell you that a change will break your code. They expect you to be paying attention.

The absolutely worst part about all this is that your users will have to decide to either stop using your code (which isn’t always an option) or not to apply an upgrade. In the case of 4.0.1, this is dangerous. This is why I will keep telling you not to reinvent the wheel, unless the wheel really needs it. And if the wheel needs a reinvention, you should consider submitting a patch to WordPress core, because if it’s that bad, everyone should know.
28 November, 2014
No Notice For Upgrades?

About a week ago I realized I’d not see an email with the subject “[Ipstenu.Org] Background updates have finished” in a long time. A really long time. Like so long that when I looked in my email trash, there wasn’t one.

This was bad, because on Ipstenu.org I’m running trunk WordPress, which means I should get two emails a day about this. I ran to my server and scanned logs for 30 days. Nothing. And that was really bad.

I’ve been using Advanced Automatic Updates for a long time, and I love it, it works well, but it wasn’t working ‘right’ for some reason, because it wasn’t emailing me on that one site, so I uninstalled it. The problem there is that without it, how would I upgrade plugins and themes? Since I know I can control the upgrades with filters, I decided to make an mu-plugin to handle just that.

And that was when I saw I already had an mu-plugin called upgrades.php with this:

WordPress site: https://ipstenu.org/
The following plugins were successfully updated:
* SUCCESS: Akismet

Perfect!

I don’t know how fun that story was, Benny, but that’s what happened.

26 November, 2014
Multisite Favicons
One of the challenges with WordPress Multisite is that everything is on the same install. This means something that is rather trivial, like a favicon, becomes exceptionally complex and tiresome.

On a normal site, when I want to make a favicon, I just toss the file into my main HTML folder, next to that .htaccess file, and I’m done. Now, for me it’s a bit of an extra step because I use StudioPress’ Genesis theme, and it applies its own favicon. It’s probably the only thing about Genesis that makes me annoyed, though it’s right next to when my host does that for me. Still, there’s a trick with Genesis.

Because of Genesis

Genesis is my parent theme, and it defines my favicon. So I have to delete its and put in mine:
```
// No, you may not have your favicon
remove_action('genesis_meta', 'genesis_load_favicon');

add_filter( 'genesis_pre_load_favicon', 'halfelf_favicon_filter' );
function halfelf_favicon_filter( $favicon_url ) {
	return 'https://halfelf.org/code/images/favicons/halfelf.ico';
}
```
And it’s that simple.

But I’m talking about Multisite, and I want to have a different favicon per site, I end up facing a new challenge.

Because of Genesis and Multisite

I still need to tell Genesis to shove it, but then I need to check what site I’m on and call the right favicon per site and this works very well. I’m using it today (you can see the code on that other link). But what if there was another option? What if I didn’t have to code it? Because the real problem with that code is I have to do it! If someone wants a new site to have their own favicon, I have to go in and add it to my mu-plugin, save it, commit it, and push it. Ew.

Jetpack Site Icons

Jetpack has a newish feature called Site Icon. With that module activated, I can allow each site to upload their own site icon and it will make a mobile icon too where I won’t have to.

For a Multisite running Jetpack auto-activated on all sites, this is perfect. And yes, I do that because it saves me a headache of having to set it up later. I allow all sites to connect on their own, but I can also control all that from the network admin.

So what does that old code look like now?

With Genesis and Jetpack

Now my code is simple. For everyone, I kill the default favicon, and then I set my own:
```
// No, you may not have your favicon
remove_action('genesis_meta', 'genesis_load_favicon');

global $blog_id;

add_filter( 'genesis_pre_load_favicon', 'example_favicon_filter' );
function ipstenu_favicon_filter( $favicon_url ) {
	return 'http://example.com/images/favicons/example.ico';
}
```
And the best part is if I set a site icon in Jetpack, it uses that instead.

Best of both worlds.
24 November, 2014
Including Assets

I’ve noticed a trend in plugin reviews that people are including third party assets with their code.

This is great. Heck, I do it on a couple of mine. Why should I reinvent the wheel when I’m including code? If I need to use some existing code like a GPL friendly lightbox file, I’ll just grab Colorbox and be happy. But have you ever really looked at your assets?

The above image shows you all the files and folders included in Colorbox. If I was including the entire git repository in my plugin, it would take up about a meg of space. The unminified js file is only 29 KB. For me, it’s a no-brainer again. Grab just the js file (making sure the header has the license info and the URL) and toss that in my code. Why would I include a meg of data I’m not using just for the ‘ease’ of a git clone?

And really I think that’s what’s happening. We’re all so excited to use a git pull or a submodule for the ease of inclusion, we stop thinking about exactly what we’re including in our code and how much weight we’re accidentally adding to it by dumping the whole library in there. Some libraries, like Complexify are really small. Then you have Twemoji, which weighs in at 135 MB, give or take.

Do you really need the whole thing in your plugin, or can you just call their JS remotely from their CDN? That’s one of those things I’d certainly recommend for most people. Sure, I’m the biggest complainer about people off-loading code, but I also am reasonable and logical. Having everyone load a 130+ meg plugin isn’t sustainable, when Twitter’s made a nice way to do it remotely. That’s a service like a font that’s okay and understandable. After all, I hate that WordPress has to call the new fonts on the dashboard from Google, but at the same time including all the fonts for all the languages would make WordPress 11 megs more. That’s just crazy.

Mind you, I had the shower idea that we could make WordPress download the fontpack when it downloaded the language packs, but we’re not anywhere near that yet. Still, that would kill two birds with one stone in my mind. It’s also illustrating the point of being thoughtful and reasonable about the assets we include in our plugins. You don’t need all the documentation files for a js plugin or most php ones either. It’s certainly easier to just drop the whole package into place, but it’s not always best. If one of those example files has a vulnerability, great, you just shot your user base in the foot.

Limit what you put in your plugins. It’ll be easier that way.

21 November, 2014