peter8nss

I’d worked out what arguments I needed. Unfortunately, the code function headers don’t reflect this reality, so when I do static analysis of my own code with phpstan I get errors on those calls – because they say that only two arguments are expected not 2, 3 or 4 depending on the first argument.

You might want to get the published ORM documentation updated to reflect that, as the example for “order_by” is:

$events = tribe_events()
    ->order_by( 'start_date', 'DESC' )
    ->all();

In case it helps, I’ve found the error message from call ->where( ‘starts_between’, $array ):

PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function Tribe__Events__Repositories__Event::filter_by_starts_between(), 1 passed in /var/www/html/wp-content/plugins/the-events-calendar/common/src/Tribe/Repository.php on line 1043 and at least 2 expected in /var/www/html/wp-content/plugins/the-events-calendar/src/Tribe/Repositories/Event.php:510\nStack trace:\n#0 /var/www/html/wp-content/plugins/the-events-calendar/common/src/Tribe/Repository.php(1043): Tribe__Events__Repositories__Event->filter_by_starts_between(Array)\n#1 /var/www/html/wp-content/plugins/the-events-calendar/common/src/Tribe/Repository.php(1246): Tribe__Repository->apply_modifier('starts_between', Array)\n#2 /var/www/html/wp-content/plugins/the-events-calendar/common/src/Tribe/Repository.php(1151): Tribe__Repository->modify_query('starts_between', Array)\n#3 /var/www/html/wp-content/plugins/the-events-calendar/common/src/Tribe/Repository.php(531): Tribe__Repository->by('starts_between', Array)\n#4 /var/www/html/wp-content/plugins/octavi_osm_core/class-signup.php(1051): Tribe__Repository->where('starts_between', Array)\n

Can you also check the where function. It appears to be defined with two arguments in the code (and comments), but the ORM documentation suggests 3 can be passed for starts_between and ends_between and even more for date_overlaps.

I had (wrongly) assumed that where multiple dates were required they would need to be passed as an array. That causes an error, whereas passing them as separate arguments appears to work.

Not removed. Just the second argument. So it would be:

/**
  * Filter imported from V1 of Views, kept since there was no requirement to
  * remove the backwards compatibility here.
...
 */
$after = apply_filters( 'tribe_events_after_html', $after ); // Second argument removed.

...

$after = apply_filters( 'tribe_events_views_v2_view_after_events_html', $after, $view );

Whilst you are correct:

• get_option is cached – so only called once per page for each option not autoloaded
• including unused options in autoload is undesirable – because it increases resources used by wp_load_alloptions

The options mentioned are “used”, otherwise they wouldn’t appear in every page load. So instead of one database read (for wp_load_alloptions) there are five database reads (wp_load_all_options + 1 each for the other options). And that is for every page load.

I appreciate that some of these may be linked to a framework you use rather than your own code. Perhaps you could pass the message on to them and help improve multiple plugins in the process.

I was worried that the problem might be specific to my configuration, so I went to a new site I’m developing that didn’t have Forminator installed and minimal other plugins. I installed Forminator and went to the site’s home page. Same result!

I don’t think it is to do with the PHP version. And I can’t seem to cause it again.

Is “css_target” a recently added setting stored in (array) option “bodhi_svgs_settings”. If so, I suspect the first time you read it you get the PHP warning, but the following code then adds it so that you don’t see the warning again.

Don’t think that filter is relevant as it is affects setting the autoload value when writing to the database. Whereas this topic is about entries that have never been written to the database.

Simpler workaround is just to add the option once through the CLI:

wp option add as_has_wp_comment_logs no

I updated the database using WP CLI:

wp db query "UPDATE <db>_options set autoload='yes' where option_name like '__ina%';"

Also had to force a save of the role based settings as there was no value in the database for “__ina_enable_timeout_multiusers”. So that was still being individually loaded.

Thanks for your help.

You are correct that 0.0005s is not going to make much difference, but you won’t be surprised to know that your plugin is not the only one that has “unnecessary” get_option calls. And its starts adding up.

Yes I am using Query Monitor plugin to find these.

The first two both arise from the plugins_loaded hook so will be triggered just because Forminator is one of the plugins even when loading pages it isn’t used on.

The trace back for forminator_activated_addons option is:

1. get_option()
   wp-includes/option.php:197
2. Forminator_Integration_Loader->__construct()
   wp-content/plugins/forminator/library/class-integration-loader.php:130
3. Forminator_Integration_Loader::get_instance()
   wp-content/plugins/forminator/library/class-integration-loader.php:52
4. Forminator->init_addons()
   wp-content/plugins/forminator/forminator.php:310
5. Forminator->__construct()
   wp-content/plugins/forminator/forminator.php:104
6. Forminator::get_instance()
   wp-content/plugins/forminator/forminator.php:85
7. forminator()
   wp-content/plugins/forminator/forminator.php:509
8. do_action('plugins_loaded')
   wp-includes/plugin.php:517

In may be worth checking your database to see whether these options are present in your test configuration database – perhaps because you have some add-ons. If they are in the database, then I assume they are autoloaded, and hence you won’t see an individual call to get_option using query monitor.

Might be a problem that autoload value only gets updated if the option value actually changes. So those values with autoload set to “no” will stay at “no”.

Rule which matched post (of any post type)

That would be helpful. Thank you.

REST API

I agreed WordPress’ approach to what is visible using REST API is a bit odd.

Whilst I do have some of my own code to lockdown REST API, I would like to make as much use of the Content Control provided functionality as possible.

However, I’ve noticed the following REST API behaviour. If I’m logged in at a browser and I issue a request …/wp-json/wp/v2/pages/<page_id>. If <page_id> is for a page that matches a restriction:

• for not logged in users, then the request is allowed.
• that my browser’s logged on user can see, the request is still refused

Presumably the latter is because the REST API is not considered to be logged in, but it does seem odd that the same browser can view the page content but not the json REST version of it.

What exactly is going wrong at the moment

With the various points already discussed in this and other topics I think my problems should be addressed.

Thank you for your detailed response. Sorry this topic is now covering quite a few separate issues

WP_CLI:

Agreed it is debatable how this should behave, and the filter is a relatively simple alternative. So no action required.

Entire site rule:

• I accept it could be used to allow login or restrictions.
• With the introduction of Query Terms, it might be useful to have a rule which matched any post (of any type) and returned false if used to test a query term.

REST API

Would be nice to have a filter that allowed REST API checking to be turned off, as many people won’t need it, or will already have something else dealing with it.

Query Terms:

I accept that rules about “is page…” etc will bail early when encountering a term query. The problem is the negation rules. For instance “is not page…” will generate true for both “posts” and term queries!

See also Term Rules Oddity

My situation

I have a site where the content visibility can splits into three groups:

• Public – available to anyone whether logged in or not
• Members – default if content is not marked otherwise, available only if logged in
• Leaders – a few pages, etc marked for limited viewing by certain roles

This is implemented by having a custom taxonomy with values Public and Leaders. And two restrictions:

• 1 leaders only
  • General: Logged in users with a few specific roles
  • Protection: Redirect
  • Content: Pages with <my taxonomy> = Leaders
• 2 Not public
  • General: Logged in users any role
  • Protection: Redirect
  • Content: Not Pages with <my taxonomy> = Public AND not search page

Which worked until Query Terms were introduced and still works fine if I turn it off using a filter.

The reason I’ve noticed so much about query terms is that I use two plugins: The Event Calendar and Quick and Easy FAQs. Including bits of their content on pages means I get queries when loading some pages and hence stumbled across the problem. And my mathematical/IT background made me curious about the implication of negation rules.