Joe Westcott

Whatever it’s worth, I searched this forum before reporting this problem.

I found a note from four months ago that the “non-standard implementation” warning was a known issue, but there was no mention of whether it’s been fixed in the past four months. So I’m not sure whether I’m affected by a known issue or whether the Tag Assistant error is specific to my setup.

I also found mentioned of the double script problem, but no solutions that seemed to apply here, so I’d appreciate any help!

Thank you, Tobias. If you ever decide to build out features like the ones mentioned in this ticket, my organization would be interested in a paid recurring license / subscription, if you ever set up such a thing. I’m sure that others would be interested in a paid Pro license as well.

In the meantime, thank you for building TablePress, and for doing all that you do.

Joe

I see. Would it be possible to disable the pagination option automatically for tables that use colspan and rowspan in the body?

This would prevent people from expecting the pagination feature to work in cases when it’s not feasible.

Thank you for considering it.

Thank you, Nastia!

Got it, Adam. That helps a lot, thank you!

Congrats on your newest family member, Danny!

And thank you for the fix! I just confirmed that comma-separated URL targets now work as expected. Thank you!

Best of luck, Danny!

Is there a way to target a comma-separated list of URLs, instead of manually maintaining a list of page IDs?

It seems that this functionality exists in Boxzilla as the “if URL contains” targeting, except for this bug where only the first URL works.

Hi Harish, if I switch to “Page is” and I use page slugs, those work as expected, but I have pages such as /about/us/ on this test site, and that’s why I’m trying to use “URL contains” matching instead.

For what it’s worth, I checked out https://make.www.ads-software.com/themes/ and the “Support” link on that page leads back here. :/

I’ll look into joining the Theme Review discussion to see if there’s a way to flag this issue and discuss potential fixes.

• This reply was modified 5 years, 12 months ago by Joe Westcott. Reason: Now with less "grumble"

Actually, in an ideal design, WordPress guidelines would state the the use of index.php files should be restricted to paths that are directly accessible by the public, including search engine crawlers and other bots.

Or else if a given index.php file is not meant to be publicly-accessible, then the theme developer should manually insert code to the start of their index.php file to indicate as much, and then exit or fail gracefully.

Preferably, this would not generate a PHP error message, because (1) the PHP code has not failed and (2) the visitor is exhibiting anticipated behavior even if the behavior is not desirable in many contexts.

Google won’t report a WordPress error page as an issue

Two things about this:

1. The theme-index error is a PHP error generated outside of WordPress, not an error page generated by WordPress or the theme itself. It would be nice if WordPress themes handled the error.

2. I’ve seen Googlebot try to index theme index files, and report a problem when it does. This problem appears in Google Search Console fairly regularly for some sites that I’ve managed.

Yes. The resulting error message is currently handled by the server, not by the theme, which is why this particular error appears.

I think I made a mistake in suggesting the “script kiddies” language that the official WordPrss guidelines suggests for handling this scenario (for plugins) — the error could be a bit more helpful whether it’s for themes or plugins, to cover cases where real people are visiting the index.php file, not just bots and scripts.

“You’re doing things wrong.”

@anevins, do you know why Taariqq is visiting this URL? Did you rule out that perhaps it’s to recreate the problem where Googlebot visits this URL and generates a PHP error as part of its typical crawling activity.

If Google is “wrong”, that may be, but this also seems to indicate a problem with how some WordPress themes fail to block crawling in locations where legitimate bots are likely to go.

@taariqq, there seem to be a flaw in WordPress guidelines for themes, where WordPress guidelines are missing a step that are already part of the plugin guidelines.

For now, it seems that your only option is to point out this problem to the theme developer, and ask them to block this behavior by adding code like the following to the index.php file, in order to block typical bot and script kiddy behavior. This code comes from WordPress’ official guidelines for plugin development — not sure why it’s missing from the theme guidelines.

defined( 'ABSPATH' ) or die( 'No script kiddies please!' );

Damned bots. I’m getting these errors several times a day.

Why does Automattic(?) recommend the following code for plugins, but not for themes?

Per https://codex.www.ads-software.com/Writing_a_Plugin

Security Note: Consider blocking direct access to your plugin PHP files by adding the following line at the top of each of them. Also, be sure to refrain from executing sensitive standalone PHP code before calling any WordPress functions.

This can be achieved in a few ways. You can either check to see if the ABSPATH constant is defined, or check if a function such as add_action exists. Either method can be used to ensure PHP execution is only allowed when it is included as part of the core system.

defined( 'ABSPATH' ) or die( 'No script kiddies please!' );