How does the priority parameter work?

Oh and by the way, I don’t know if this is important or not but from my first plugin (which I copied some code from another well know plugin as I didn’t know how to go about it) I have always added these functions to my funcs.php file just in case WP ever removes add_filters or add_actions.

if ( !function_exists('add_filters') ) {
	function add_filters($tags, $function_to_add, $priority = 10, $accepted_args = 1) {
		if ( is_array($tags) ) {
			foreach ( (array) $tags as $tag ) {
				add_filter($tag, $function_to_add, $priority, $accepted_args);
			}
			return true;
		} else {
			return add_filter($tags, $function_to_add, $priority, $accepted_args);
		}
	}
}

if ( !function_exists('add_actions') ) {
	function add_actions($tags, $function_to_add, $priority = 10, $accepted_args = 1) {
		return add_filters($tags, $function_to_add, $priority, $accepted_args);
	}
}

I don’t see how this would effect anything but I thought I should let you know in case you know something I don’t.

Don’t worry I solved it!

I thought I had put it in this forum but I must have been speaking to someone else.

The problem was due to the is_plugin_active function which is only allowed to run when you are logged in AS ADMIN. Which explains everything perfectly (see https://codex.ww.wp.xz.cn/Function_Reference/is_plugin_active )

I couldn’t run the same code from a CRON / GET request as I wasn’t logged in as admin so it bombed out on that line. But when I was in admin posting everything worked as expected.

I have replaced that line of code with a check for my strictly_auto_tags wp_options array so if it’s there I know autotags is installed and can use that instead of the check for the plugin.

It doesn’t solve the question of why so many plugin initialisers are called all the time (lots from the looks of things) which is why I asked the best way to declare objects (singletons or just $myobj = new myobj(); at the bottom of the page)

Also someone could in theory have the plugin on their system – de-activated which would mean tagging wouldn’t run. But I do offer a “uninstall” when de-activating option so that should solve the majority of cases.

Thanks for your help – although I was pretty sure I replied to it yesterday.

Hi

It does say that the function is only available in the “admin pages” e.g

NOTE: defined in wp-admin/includes/plugin.php, so this is only available from within the admin pages, and any references to this function must be hooked to admin_init or a later action. If you want to use this function from within a template, you will need to manually require plugin.php, an example is below.

So I take that as having to be logged in as admin and using the admin_init hook OR including the plugin code.

I’m not actually sure what within the admin pages logically means which is why I am presuming it is to do with being logged in as an admin AND in the admin area of the site when running the code.

This would also make perfect sense to why I can post an article OR call WP-O-Matic in admin and the code was working okay but when I called the page in the plugin folder/test page in the root directory from a GET request it bombed out on that function call.

I did put a reply up (or I thought I did – must have a dupe thread somewhere OR comments not submitting) which showed that when I moved that is_plugin_active code to the top of my test page and just below the

require_once(require_once($_SERVER["DOCUMENT_ROOT"] . "/wp-config.php");

That the test GET request was just dying as soon as it got to the is_plugin_active function call.

This is what made me think the two were related.

You are right a test for function_exists would probably be better as long as WP load in all plugins before any code can be ran?

The reason I ask is, if AutoTags was loaded AFTER the tweetbot plugin would function_exists still be able to see all the functions in the AutoTags plugin?

If WP loads in all the plugins first on every page THEN lets people do stuff with them it would be okay.

However like you, I really don’t see the need to load in every plugin on every page. It really must kill performance to load in plugins that are only related to saving posts on pages where people are just viewing posts AND vice-versa.

Could WP not have some sort of plugin_use tables/object that the plugin author defined where their plugin (or even each plugin action) was to be used?

E.G if my autotagging plugin is only used when a post is saved then the code doesn’t need to be loaded when a page is displayed.

Or if code is linked to a button that can only be hit in admin then (e.g to manually rebuild a sitemap) then it doesn’t need to load that plugin code in anywhere else in the site.

This would allow WP to only load in the relevant plugins FOR the actions being carried out rather than ALL of them ALL of the time.

You are right in that when I made my first plugin and delved under the covers of WP I was horrified at the amount of duplicate function calls and code being run. It must really hurt performance with all the duplication going on. It is also the reason I learnt PHP a few years back.

I remember my first plugin was a sitemap plugin that I had to write due to getting out of memory errors when it was rebuilt each time.

The answers I was getting from people was to just increase the memory allowance for it. It seemed like the same functions were being called on every loop iteration (e.g to get permalink structures for categories, tags, posts, pages etc) rather than just getting them once before the loop.

So I decided to handle the problem myself, learn PHP, and write my own Sitemap plugin. It can either use pure SQL to build up the recordset instead. OR use SQL to get each section (pages, posts, categories, tags) and then PHP to join them together.

With my plugin (which I still use even though the SEO parts are a bit redundant now due to Google/Bing changing how you can use their search engines to make requests), the maximum number of SQL calls to the WP DB is always 7, this is the case whether you have 1 or 100,000 posts on your site.

With other plugins (at least at the time I wrote mine) the number of DB calls increased as the number of posts being outputted in the plugin went up.

I did a little comparison test which you can see here > http://www.strictly-software.com/plugins/strictly-google-sitemap and you can see in the comparison table (about halfway down between my plugin and 2 others) which compares two different permalink structures:

/%year%/%monthnum%/%category%/%author%/%postname%/%post_id%/
/%year%/%monthnum%/%postname%/

That the number of DB calls was constant with my plugin when compared to the others. It also shows the full amount of records (pages, posts, categories, tags which can be listed in the sitemap), Database calls and the amount of memory used for each (a small site and a larger one).

This was a few years back now when I only had 7000 posts, now I have 40,000+ so it’s even more important that I squeeze every bit of performance I can out of the system and any plugins.

I suppose this is why I do my deep-linking with my AutoTagging plugin on INPUT (when a post is saved) and not on OUTPUT (when it’s shown) as it reduces the amount of work needed (you may save once but display it 100,000+ times).

I also ban 45%+ of all my traffic (bad bots, hackers, spammers, whole country IP ranges, whole Amazon subnets etc, short user-agents etc) to keep the traffic down to legitimate users.

I need the code to be quickly loaded and optimised and I have had a real nightmare with a LAMP + WP set-up to get it to run as fast as possible without just throwing more RAM+CPU at it. The amount of PERL, BASH, MySQL optimizer tools and so that I have had to learn to get the stats I need is way too much, but then that could be seen as a good thing as they are all new skills for my CV!

I am used to Windows (.NET C# ASP) and MS SQL (day job) which have beautiful diagnostic tools for improving DB speed, finding missing indexes and logging useful stats. This is why I find the lack of nice visual diagnostic tools on LAMP very poor in comparison.

I have often thought that a tool that could link a servers load (uptime, CPU, memory, disk swap etc) with the error/access/MySQL slow query log etc so that you could see what URLs/Queries were being hit and by who (IP/Agent) when a CPU or Memory spike, error or connection issue occurred. Or the biggest hitting IP/UserAgent that caused the most errors etc would be FANTASTIC.

I even got to the stage of nearly attempting to write one myself at one point. However the nearest I got before solving my own issues was writing another system check plugin which doesn’t load in all the WP code, copies the DB constants (to keep it quick and not reliant on any WP issues) and it makes scheduled HTTP requests to a site to log Server Load, No of SQL queries running, long queries, connections, time to load the page and some other stats. Then if there is a problem you can set it to auto optimize/repair your tables OR just send a warning email to you if problems are found.

I still think a tool linking all those log files and server values (CPU/Memory/Load) would be great though!

I even wrote a 3 stage WordPress survival guide for my own sanity and to help others moving from Microsoft to LAMP >
3 part WordPress Survival Guide

Whilst I am glad I now know PHP/MySQL/Linux/Apache etc there is sooo much I would change if I could re-develop the codebase for WordPress but then I have my own day job to keep me busy at the moment!

Thanks for your help!