reasonx

Hi,

okay, then I will investigate further and search for the problem on our side. Thank you very much for your help.

Best regards

Hi,

thank you very much for your answer. I was already using version 4.0.12 of PLF. And the error also occours when switching off all plugins except tablepress & PLF.

After your answer I testet it again and I found out, that the error only occurs when using PHP 8.1. If I switch my local environment back to PHP 7.4 it works fine. That is because in PHP 7.4 PHP only throws a warning whereas in PHP 8.1 PHP throws a fatal error. Did you also test with PHP 8.1? If not, you could try again to reproduce the error. You have to create a table and then insert an image to a table cell. The Ajax call should return an PHP Error when running PHP 8.1.

In the meantime tablepress got updated to version 2.0.2 so I installed that update. Unfortunately the problem still exists.

Maybe the stacktrace is helping:

[error] FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught TypeError: urlencode(): Argument #1 ($string) must be of type string, array given in /wp-includes/formatting.php:5525

Stack trace:

#0 /wp-includes/formatting.php(5525): urlencode()
#1 /wp-includes/class-wp-query.php(2134): wp_basename()
#2 /wp-includes/class-wp-query.php(3749): WP_Query->get_posts()
#3 /wp-includes/class-wp.php(663): WP_Query->query()
#4 /wp-content/mu-plugins/plf-filter.php(1020): WP->query_posts()
#5 /wp-content/mu-plugins/plf-filter.php(298): Plf_filter::plf_filter()
#6 /wp-includes/class-wp-hook.php(310): Plf_filter::active_plugins()
#7 /wp-includes/plugin.php(205): WP_Hook->apply_filters()
#8 /wp-includes/option" while reading response header from upstream, request: "POST /wp-admin/admin-ajax.php HTTP/1.1", referrer: "/wp-admin/admin.php?page=tablepress&action=edit&table_id=609"

As I said my current workaround for this is to put this code

if (!empty($_POST['action']) && $_POST['action'] === 'send-attachment-to-editor') {
    return false;
}

into /mu-plugins/plf-filter.php before $GLOBALS[‘wp’]->query_posts();

Thank you very much for your help.

Wow, what a fast answer ?? Thank you very much.

Hey,

we got it to work finally. But there is one downside. We have to put one line of code into a plugin file.

wp-content/plugins/amp/includes/class-amp-theme-support.php:491
$query->is_singular = true;

That′s because $query->is_singular() is returning false if we don′t put in the line and therefore the amp plugin redirects to the non-amp version (302).

I know it′s bad practice and we have to put the line in after every plugin update but there′s no hook in that function and it′s the only way it works at the moment so we will do it that way.

you can close the ticket ?? Thank you for your help.

Hi @milindmore22

thank you for the reply.

our entry for the custom post type looks similar. The rewrite is set to

'rewrite' => array('slug' => 'testberichte', 'with_front' => false),

but after the post-types are set up we are using a dynamic routing for posts with that post type because one part of the slug is dynamic. We are using core wordpress functions like add_rewrite_rule() and add_rewrite_tag() for this. I don′t want to put all the code of our routing classes in here but here you have the regex for the rewrite to get an idea:

'test_amp' => new Route('^(handys)/([0-9A-Za-z\-_]+)/(test)/(amp)\s*$', array('productKind', 'urlAlias1', 'page', amp), 'ProductReviewController'),

So the workflow is like this:

1. A visitor requests /handys/samsung-galaxy-a53-5g/test
2. Our Routing Class jumps in very early in the init hook and registers a rewrite rule for that specific url pattern (and others)
3. WordPress recognizes the rule and the url and loads a specific controller class. In this case it is “ProductReviewController”
4. Within the controller we do all sorts of things, we manipulate the query, hook on to several hooks and tell wordpress which view to load.
5. Now that the controller is processed and the query is set up wordpress works all the way down until the post data is used in the view

In that way it works like a charm for the non-amp version. As you can see in the regex above I have already added /amp to the path and that also works. The controller is loaded when a request to /handys/samsung-galaxy-a53-5g/test/amp is made and I can hook into pre_get_posts and set query properties like is_singular = true; and other stuff I mentioned in the initial question.

So my assumption is that the plugin is not able to recognize this url as a valid url since it awaits the slug which is set in the post type registration (/testberichte/xxxxx/amp) but only gets /handys/xxxxxxx/test/amp.

I was hoping we can somehow manipulate WP_Query to tell the amp plugin it can load the post as a normal amp post even if the url is beeing routed to a controller and all that stuff ?? But maybe it′s not possible at all.

Thank you very much for your time

Hi,

that′s awesome!! Thank you very much for your effort. We didn′t expect this support request to be solved so well and so fast. We appreciate that and we take this into account for the purchase of the pro version we will do in the near future.

Best regards,
Arvid

Hi,

thank you very much for the fast response. We appreciate that. In the meantime we have tracked down or at least delimited the problem in the code. Please keep in mind that this behavior is only reproduced when both plugins are active.

1. foogallery/includes/admin/class-admin-css-load-optimizer.php line 49

if ( false !== ( $css_location = $this->_locator->locate_file( "gallery-{$template}.css" ) ) )

This check returns false ALWAYS. Therefore the following post_meta entry is never performed.

2. foogallery/includes/public/class-css-load-optimizer.php line 117

if ( is_array( $enqueued_foogallery_styles ) && ! array_key_exists( $style_handle, $enqueued_foogallery_styles ) )

This check does not seem to be enough because the following add_post_meta() is performed over and over again until the timeout which leads to thousands of entires in the DB. The loop is somehow created by elasticpress. They hooked a sync method on the “added_post_meta” Hook which gets triggered every time. You can look up the method in elasticpress/classes/class-ep-sync-manager.php on line 94 or the add_action on line 45 in the same file.

Essentially this method fills an array which is later evaluated in a foreach loop.

Whatever the problem is in detail, we have fixed it for now by removing the “add_post_meta()” in the class-css-load-optimizer.php on line 127. Of course, if we want to update the Plugin, the changes are gone so we hope it gets fixed in future versions ??

Best regards