Controlling load order of enqueued WordPress scripts and stylesheets

Another in a long line of stuff that is easy to do once you find out how to do it.

I was working on a WordPress theme and I wanted to incorporate UI Kit into this theme. I was trying to be a good WordPress citizen and so was enqueueing both UI Kit’s CSS and my main CSS. I’m honestly not convinced this is necessary for a theme you’re building for a specific site but what the heck.

My concern was, UI Kit has a lot of default styles that I was intending to over-ride [we weren’t organized enough for me to go with a custom UK Kit theme] in my style.css file, so it was important that style.css get loaded last.

So, we need to do two calls for the enqueueing. First we load up UI Kit’s CSS and javascript files:


function mytheme_scripts()
{
// UI Kit
wp_enqueue_style('uikit', get_template_directory_uri() . '/css/uikit.min.css');
wp_enqueue_script('uikit', get_template_directory_uri() . '/js/uikit.min.js');
wp_enqueue_script('uikit_icons', get_template_directory_uri() . '/js/uikit-icons.min.js');

}
add_action( ‘wp_enqueue_scripts’, ‘mytheme_scripts’ );

Then we make a second add_action call to enqueue style.css, Note the trailing 99 in the add_action. That represents the priority, or order files will be loaded. The default is 10. 99 might be overkill but if we ever need to add something between the two we have ample ‘room’ to do so.


add_action('wp_enqueue_scripts', function(){
wp_enqueue_style('main-style', get_template_directory_uri() . '/style.css');
}, 99);

If we view source of the page it looks like this. WordPress still prioritizes style sheets before js, so style.css gets included after UI Kit’s css but before UI Kit’s javascript:

<link rel='stylesheet' id='uikit-css' href='https://dev.sample.local/wp-content/themes/sample/css/uikit.min.css?ver=5.3.3' type='text/css' media='all' />
<link rel='stylesheet' id='main-style-css' href='https://dev.sample.local/wp-content/themes/sample/style.css?ver=5.3.3' type='text/css' media='all' />
<script type='text/javascript' src='https://dev.sample.local/wp-content/themes/sample/js/uikit.min.js?ver=5.3.3'></script>
<script type='text/javascript' src='https://dev.sample.local/wp-content/themes/sample/js/uikit-icons.min.js?ver=5.3.3'></script>

Simple enough. One of those things where it took me longer to realize I could add a priority to add_action than it did to make the change.

One thing to try when Wordfence breaks your server

I opened up my local copy of one of our sites today and… white screen. WTF, it was working fine the last time I used it. I hit reload and now I’m getting a server not found error. That’s weird.

So I check the log files and see this:

[Mon May 07 15:09:14 2018] [notice] Child 167276: Starting thread to listen on port 80.
[Mon May 07 15:09:16 2018] [notice] Parent: child process exited with status 255 — Restarting.
[Mon May 07 15:09:17 2018] [notice] Digest: generating secret for digest authentication …
[Mon May 07 15:09:17 2018] [notice] Digest: done
[Mon May 07 15:09:19 2018] [notice] Apache/2.2.31 (Win32) DAV/2 mod_ssl/2.2.31 OpenSSL/1.0.2e mod_fcgid/2.3.9 mod_wsgi/3.4 Python/2.7.6 PHP/7.1.7 mod_perl/2.0.8 Perl/v5.16.3 configured — resuming normal operations
[Mon May 07 15:09:19 2018] [notice] Server built: May 6 2016 10:19:53
[Mon May 07 15:09:19 2018] [notice] Parent: Created child process 50416
[Mon May 07 15:09:20 2018] [notice] Digest: generating secret for digest authentication …
[Mon May 07 15:09:20 2018] [notice] Digest: done
[Mon May 07 15:09:21 2018] [notice] Child 50416: Child process is running
[Mon May 07 15:09:21 2018] [notice] Child 50416: Acquired the start mutex.
[Mon May 07 15:09:21 2018] [notice] Child 50416: Starting 64 worker threads.
[Mon May 07 15:09:21 2018] [notice] Child 50416: Starting thread to listen on port 80.
[Mon May 07 15:09:23 2018] [notice] Parent: child process exited with status 255 — Restarting.

This repeated over and over. Apache was starting but when I attempted to load the site, it would crash. If I tried to load something simple that didn’t involve wordpress, everything worked fine.

Long story short, something had become foobar’d with Wordfence. Not blaming the plugin itself, I think I munged something up when I imported a fresh SQL dump. I usually don’t pull over wordfence directories but maybe I screwed up, who knows?

The fix is simple enough.

Step 1:
Delete everything in \public_html\wp-content\wflogs

Step 2:
Truncate all the wp_wf* tables in your database.

Bam, problem hopefully solved. Wordfence will recreate the files you delete and re-fill that tables as it needs to. And your local will start to work again. Huzzah!

Now if it happens again, you might have a bigger issue. What turned out to be the problem in my case was that Wordfence was exhausting Apache’s memory, essentially. This only happened for me in a MAMP environment; I never ran into the issue with my Docker-based locals.

I fixed it by tweaking the Apache ThreadStackSize by inserting this into http.conf:

ThreadStackSize 8388608

Since I was on MAMP I had to edit a template. See this post for more on dealing with MAMP templates.

Apparently (I read this on the Internet so it must be true) MAMP sets a much smaller default stack size (1 MB) as compared to a typical Linux installation (8 MB). So the above ThreadStackSize pushes the size to the same as you’d find on linux.

Excluding a directory when creating a tar file

So this is a dumb one but it took me longer than expected to find an answer.

So say I want to make a local copy of a wordpress site. I want to tar up all the files to download because downloading the files one by one will take hours and hours.

Assuming a directory structure like

/www/public_html/index.php

I would normally go to /www and do

tar -zcvf mysite.tar.gz public_html

That gets everything…much faster to ftp.

But on some of our sites, we wind up with a BIG cache and I really don’t need all that stuff. In our case the cache is at:

/www/public_html/wp-content/cache

So how to exclude the cache files? There’s an –exclude flag for tar but it seems finicky. Turns out it has to be the first parameter, at least for me and some others.

So this worked for me:

tar --exclude='public_html/wp-content/cache' -zcvf mysite.tar.gz public_html

This did NOT work for me
tar -zcvf mysite.tar.gz public_html --exclude='public_html/wp-content/cache'
Nor did this:
tar -zcvf --exclude='public_html/wp-content/cache' mysite.tar.gz public_html

–exclude seemed to only work when it came first after the tar command.

Cleaning up a WordPress wp_options table bloated with transients

I’ve got a pair of wordpress sites under my care that have an issue with the wp_options table getting bloated. I mean, really big. Millions of rows for a modest sized site. I suspect it has something to do with the Yoast plugin but I’m not 100% sure. At some point I need to figure out WHY this happens but in the meantime I’ve just been treating the symptoms, so to speak. Every month or so I go in and clean up the tables.

Basically what is happening is that a bunch of transient records aren’t expiring or getting deleted or whatever they are supposed to be doing.

Live example from one of these sites (which, I should add, is running on MySQL)

select COUNT(*) from wp_options
2284298

I’ve actually seen it bigger.

So how many of these records are transients?
select COUNT(*) FROM `wp_options` WHERE `option_name` LIKE ('%\_transient\_%')
2274527

So all but 9,771 rows are transients. Even 10K rows seems pretty big for wp_options but for now I’ll pick my battles.

So time to clean up. Step 1 is always to backup the database first, or AT LEAST backup the wp_options table. I prefer to wait to do this late at night or very early in the morning, just in case it impacts performance.

Once you have a backup, do the cleanup
DELETE FROM `wp_options` WHERE `option_name` LIKE ('%\_transient\_%')

Then recheck the count:
select COUNT(*) from wp_options
10054

Much better. And now we’re set for another month or two.

As I said, I’ve been having to do this for a couple sites for a while now, and so far haven’t seen any negative impact from nuking the transients, but as always, I don’t assume responsibility for any damage you cause to your site!