Something it really took me a long time to learn!

It's applicable to existing code too, where you might want to alter the output of something that's already scripted, something I've been trying to do on this page for some time.

Good info. Worth a share.

WordPress, the free and open-source content management system still used the most of any one CMS on the planet - still growing its userbase and monopoly on the overall Internet share of websites it powers by the year (43.2% of everything in 2022 - which is almost half a billion), has probably managed to maintain said powerstatus thanks to in part an innate simplicity of use, a constantly expanding base of developers plugins and themes, but also because it's managed to balance innovation and compatibility and tradition in an acceptable way.

Though for example you're of course recommended to always have the latest version installed you don't have to - you still have control - which is more than you can say about even as important a thing as your OS.

And when they roll out new and sometimes unconventional features like the Gutenberg template builder, they do cater to user demand and also keep the traditional post editor when not everyone is happy with their new move. Updates are flexible, and both improvements and innovation seem to go through a heavy phase of consideration pre-implementation, but as is the nature of all things that grow and evolve whilst maintaining the same foundation it does also become all the more cluttered, and not all additions are good ones, though of course good is relative...

Like for example the heartbeat. In my humble a not that good addition.

Why? Well because it increases the performance requirements for your platform greatly. It's a feature that allows the platform to speak to WP servers and trigger certain actions on certain events - basically it's an API - that lets you do useful things like autosave your posts. But it does run constantly, and it gets trigged constantly - on both front and back end - and of course this provides significant additional load to your server.

There's no built in way to control this! You'd think they'd allow some wp config options for it if not actual options via the admin panel, but no. It was introduced in 2013 and such features still do not exist, so unless you know about it runs constantly, and shared hosting providers may prompt you to upgrade your plan to allow it.

You can however disable it entirely with a function:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
wp_deregister_script('heartbeat');
}

Add that to your functions.php if you wish to.

There's also a handy plugin that lets you limit certain aspects of it too - like for example just front-end triggers - which to me personally are not at all as important as say the back-end autosave functionality. Front-end triggers become all the more resource-intensive if you have lots of visitors too - they just need to keep the page open to continually consume resources.

There are some other services you could use. Paid ones, or the Litespeed Cache, that comes with other benefits. Like... caching.

I settled on the last option myself. Was introduced to it via cPanel just a while back - and it really has a bundle of other useful finesses too! I used Heartbeat Control earlier, but it's outdated, and I'm not sure it works properly for all triggers/times.

Go optimize your heartbeat y'all! Hit the gym. And the admin panel.

Like the man in mantle.

Tried changing a version number for a plugin recently, and it didn't go so well.

It took a while before I figured out that the version number in particular was causing this error, and once I did of course I wondered why.

Does WP have a built-in file integrity check? Does it actively monitor plugin versions, and variants, and check them against the corresponding file versions on the official WP plugin depository? Or could it be that some firewall I have installed is causing the issue...?

After I'd opted back to the original plugin to get rid of the error, and modified it again without modifying the version number, I also started getting an update notification for this particular plugin, even though it was already up-to-date.

So that seems to imply it's no firewall, but more so probably a built-in WP security feature.

I did some digging...

Turns out WordPress automatically looks for updates - if your plugin is hosted on wordpress.org - every twelve hours. More info here.

This is done via the wp_update_plugins cron job.

Theoretically you should be able to bypass this check by modifying the cron jobs, which is easiest done with say a plugin like WP Crontrol.

Even with Cron disabled you might need to edit some _site_transient_update_plugins fields in your wp_options table. Information in regard to what plugins need updating, when they were last checked etc etc should be stored here.

If you're working on a plugin outside the WP plugin repository you can also use manual update checks. If you need to fetch plugin data use this. If you want to host your plugins yourself and provide your own updates see this.

In my case, I was attempting to edit an existing plugin for use via my own site, which is probably why I received a critical error, though I haven't been able to find any information on why this would generate a critical error instead of say just an internal error message, notifying you that plugin files have been modified.

When I didn't change the version number - and just updated the file - it worked. But then the admin panel shows a constant 'new version available' message for that specific plugin.

Solution? Make the plugin your own.

Modify variables and file structure, change plugin title and information, make it so there is no longer a link to the official plugin repository by which the plugin can be checked, and voila, it works! No pesky notices. No dependencies. No erroneous or unnecessary version checks no longer.

As long as nobody creates a plugin via the official repository with the exact same name and number and security phrase...

For now though, at least in my case: this is working fine.

Simple thing! Just add this to your functions.php:

/**
 * This function modifies the main WordPress query to remove 
 * pages from search results.
 *
 * @param object $query The main WordPress query.
 */
function tg_exclude_pages_from_search_results( $query ) {
    if ( $query->is_main_query() && $query->is_search() && ! is_admin() ) {
        $query->set( 'post_type', array( 'post' ) );
    }    
}
add_action( 'pre_get_posts', 'tg_exclude_pages_from_search_results' );

With or without the:

/**
 * This function modifies the main WordPress query to remove 
 * pages from search results.
 *
 * @param object $query The main WordPress query.
 */

...which seems like a tad unnecessary many characters for a quick description. In collective amounts, I wonder how much commentary as such bogs down runtime...

Source here.

I had a jam game today. Deadline at midnight. Hoped I'd get it done way before then (I'm actually typing in this post around 5 PM - still have barely made it past the interface design - writing this a little ahead of time) but of course it's probably going to be done at the last moment possible...

Technically I have a few hours extra before midnight EST, but work awaits tomorrow and I didn't sleep well last night (tailbone pain all of a sudden, can't lie on my back - can't lie easily on my sides either - very problematic) so I really don't want to stay up that late if I can help it.

This is all beside the point though. Neither here nor there. Nor over there. Nor anywhere.

But anyway, the point is: I think I finished up my interface bit about an hour or so ago. Maybe even earlier. A complex mash-up of movie clips and tweens and buttons as to give the game a floating kind of feeling (you'll see if you play it) and the only thing that remained was adding in some actions to those buttons to direct the users to the relevant frames within said game... and it just wouldn't work! I used an action I'm pretty sure I've used plenty of times before, namely:

on(press){_root.gotoAndPlay(1);}

...but it just didn't happen! Nothing happened when you pressed it.

I tried copying the button outside the movieclip it was embedded in.

I tried copying it outside the additional movieclip it was embedded in within that (had one for a rotating question mark in addition the wave FYI).

I tried swapping out _root for _parent, and adding in the scene number along with the frame, and adding in a frame name instead of the number, and then actually copying the button outside the movieclip and removing that _root bit there... and suddenly it worked fine.

What's the problem? _root is an accepted parameter, so why wouldn't that work?

I've been looking through code examples and tutorials and what-not trying to figure this out, wondering if maybe a button can't be clickable within a tween, or with layered MCs, or with too many MCs on the same frame, or if there was maybe a problem with the MC name (it had a space in it, could that be it?). Tried applying the code to the MC itself instead of the button too. The MC doesn't play then, but debug doesn't say there's anything wrong with it, might actually work with button actions on an MC - finna need to test that a bit further some other time.

In the end though I settled for a working workaround. I cut out the _root bit of it all, and instead just added in a regular gotoAndPlay within the MC, beyond the last frame of the loop, with this:

_root.gotoAndPlay(4);

...and...

gotoAndPlay(1);

...on the last frame of the loop, as to keep it looping seamlessly without automatically taking the user to the aforementioned frame in the root of all should the user not click said button.

And it worked! For some reason it works when the action's applied to the frame itself, but not when it's applied to the button.

I'm battled, and slightly frustrated I spent one or two hours on this tiny thing, but that's that. And that's it for writing/spending all the more time on this thing that I don't really need to spend time on. It's functional though. Documentation and vent in one.

Now onto the rest of that game...

Noticed the maybe annoyingly frequent hyphenations on the site lately?

Lines that go li-
ke this even when they re-
ally don't need to?

I didn't until I switched to Chrome! Apparently it's a browser-based feature. Neither FireFox nor Opera had it - Chromium-based though the latter may be too it's apparently not all that similar to Chrome after all.

I don't want this stuff though.

Lines aren't supposed to hyphenate themselves. I do that manually.
I add in shy hyphens into the code so certain words hyphenate at certain resolutions, and have been planning to revise old posts eventually with this in mind, to get them looking as good as possible.

Hyphens at the end of every line just look weird.

So, the solution? I found this:

article .entry-content {
	-moz-hyphens: none;
	-ms-hyphens: none;
	-webkit-hyphens: none;
	hyphens: none;
	word-wrap: normal;
}

I tried adding it in... nothing happened. It didn't work. I kept looking. I found this too. Good alternative, though no MS compatibility here:

.hyphenate {
  word-wrap: break-word;
  overflow-wrap: break-word;

-webkit-hyphens: auto;
   -moz-hyphens: auto;
        hyphens: auto;
}

But that's not very different after all.

After digging around a little more I found this:

p {
     -webkit-hyphens: auto;
     -webkit-hyphenate-limit-before: 3;
     -webkit-hyphenate-limit-after: 3;
     -webkit-hyphenate-limit-chars: 6 3 3;
     -webkit-hyphenate-limit-lines: 2;
     -webkit-hyphenate-limit-last: always;
     -webkit-hyphenate-limit-zone: 8%;
     -moz-hyphens: auto;
     -moz-hyphenate-limit-chars: 6 3 3;
     -moz-hyphenate-limit-lines: 2;
     -moz-hyphenate-limit-last: always;
     -moz-hyphenate-limit-zone: 8%;
     -ms-hyphens: auto;
     -ms-hyphenate-limit-chars: 6 3 3;
     -ms-hyphenate-limit-lines: 2;
     -ms-hyphenate-limit-last: always;
     -ms-hyphenate-limit-zone: 8%;
     hyphens: auto;
     hyphenate-limit-chars: 6 3 3;
     hyphenate-limit-lines: 2;
     hyphenate-limit-last: always;
     hyphenate-limit-zone: 8%;
 }

...and started questioning if my manual hyphenation approach was really necessary after all.

If you actually have total control over the character amount required for automatic hyphenation to occur, and on how many lines in a row this can occur, then this would pretty much be the same thing as doing it manually after all, except you don't actually have to. Potentially plenty of time saved at no extra cost! No downside.

I tried using this too though and that didn't work either! Did some digging through my stylesheet and noticed... I'd actually enabled auto hyphenation myself in the code further down, and just hadn't been using a browser earlier with which this code was compatible. -_-

So I removed that but... it's not going away anyway.

Some plugin-related stylesheet with this built-in? Some function I've forgotten about? Something built-in with WP itself? Something browser-based after all, that I just can't override?

For now I think I'll just give this a break, but it does seem like the manner of hyphenation changed slightly after I removed my own code.

It's not as frequent now. Doesn't happen with two letter cuts. The lowest I've seen so far is three.

So that's that. Override. Don't let browsers take control. Even if you want to go automatic: manual code's the way to go!

I'll look into this some more in the future; post a follow-up then.

When I can get these lines exactly where and how I wan-
t 'em.