Jake Whiteley

Same.

Updating to the most recent plugin version seems to fix it.

• This reply was modified 7 months, 3 weeks ago by Jake Whiteley.

@mumbomedia I just found this https://github.com/Yoast/wordpress-seo/issues/19699

@maybellyne I also have this issue – only other plugin is ACF.

The error is coming from the draftJs.js external javscript file, enqueued by yoast directly.

It completely kills the ability to edit content types/taxonomies with the new Yoast UI.

I have found the issue:

In this PR the WC_AJAX::grant_access_to_download method was updated to require the downloadable product to be present in the order to be able to grant permissions.

Up until this PR was merged, any permission could be granted to any order provided the order, product, and user existed.

But now the product has to be included in that order directly.

This present an issue for me as I need the ability to grant permissions to users directly and bypass the need for them to buy the product. Up until recently I would put a 0.00 order through and grant the permissions (this was to keep our external ERP software happy and record it as a sale that didn’t generate revenue).

There is a ticket (https://github.com/woocommerce/woocommerce/issues/29884) where other people are annoyed at this change.

There is a workaround here – which is basically to add the product to the order without saving, grant the permissions, then remove the product before saving.

Also having this now in the most recent version (5.4,1) of WooCommerce.

Hi Bruce,

Thank you for keeping me updated

Hi Bruce,

That is impossible.

After deactivating the plugin cf7-multi-step\inc\frontend\validation.php will never be run, so that specific error won’t appear.

I have also tested vanilla contact form 7, and can confirm that no error log entries are created when submitting a CF7 form with an empty and non-required file input.

The error is specifically from your plugin – line 169 of inc\frontend\validation.php.

Because you said “still there” that suggests that you aren’t clearing your log between tests, so of course the error is still there – it is a static text file.

Hi,

I am using version 2.6.1 of the plugin, and version 7.4.3 of PHP.

I won’t send you a link because this is a PHP error; sending you a link to the frontend of a website won’t add anything to the discussion as the error only appears in the PHP error logs directly on the server.

Steps to reproduce:

1. Create a new multistep form with a file input (do not make the input required) in step one, and a submit button in step 2.
2. Add to a page
3. Go to the page and click the next step button without adding a file
4. check error logs

This happens because the php $_FILES array is only populated when a file is uploaded.

Looking at the code you have in that file:

$file_result = new WPCF7_Validation();

$file_tags = $contact_form->scan_form_tags(
array(
    'feature' => 'file-uploading',
)
);

foreach ( $file_tags as $tag ) {
    $file = $_FILES[ $tag->name ];

If no file is submitted, then the $_FILES global will be empty.

All that is needed is an additional check that if $tag->is_required() is false, then there should be an isset($_FILES[ $tag->name ]) conditional in order to continue processing.

Because there is an apache proxy, $_SERVER["SERVER_SOFTWARE"] is set to "Apache/2.4.46 (Unix) OpenSSL/1.1.1".

I mean, this is technically correct . The request is handled by nginx and then passed to apache as it ends up being a php file request instead of a static asset.

I can bypass this by adding SetEnv WPENGINE_ACCOUNT true to my htaccess, but ideally there should be an admin setting – “This site uses an apache/nginx for PHP files” or similar.

thoughts?

I can confirm the URL in the browser is correct and pointing to the image URL /wp-content/uploads/2020/12/Lewa-House-1-of-1-17-scaled-1600x1067.jpg.

So something about my setup is setting $_SERVER['REQUEST_URI'] it would seem?

@tobiasbg @tobiasbg @fabrizim @leonardcraft – this is fixed in the most recent version of the revisions plugin.

@tobiasbg @fabrizim Just an update – PublishPress have told me they have a fix which will be shipping in the next release.

I’m asking for a release candidate now so I can confirm and will get back to you.

@tobiasbg I am also having this issue with tablepress/publishpress revisions.

I have opened a support ticket with publishpress and will update you here on what is found.

It looks like revisions is intercepting the save action in tablepress, and creating the saved data as a revision instead of a tablepress_table.

While I am here, the plugin also causes a js error when using jquery > 3.0:

Uncaught TypeError: e.indexOf is not a function at advanced-flat-rate-shipping-for-woocommerce-public.js:42

This is from jQuery(window).load(function () {, which is deprecated since jQuery 1.8 and fully removed in jQuery 3.

Awesome, TY!