Jeffinho2016

Excellent Arno, thanks!

Can also confirm that these settings were once again disabled between 5.2.2 and 5.2.3. And this time, without a single message

Your plugin still says “The firewall functionality is achieved via the insertion of special code into your currently active .htaccess file” and “The advanced firewall rules are applied via the insertion of special code to your currently active .htaccess file.”.

If you tell us that it’s now through php, but also tell us that it goes through htaccess when we enable the option, it’s normal that no-one understands what’s going on.

I’d also like to know if the current version is impacted by this vulnerability.

For now, uninstalled the plugin on 3 websites.

Seems that some similar hack was reported 5 years ago in github?https://github.com/braekling/WP-Matomo/issues/66

Thansk!

Final update.
So it turned out that everything was working from the beginning.
The issue lays in the lack of documentation on this feature.
After wasting an entire day trying to figure what was not working.
I finally noticed that, in dev mode, there is an additional button that gets added in the sidebar, button that is called “Delete orphaned data” and that we’re actually supposed to click on it.
This button and the fact that we need to click on it is NOWHERE mentioned in your documentation.
It takes absolute luck to notice it, or hours digging in the pluging code to try to figure out why data gets merged, but not deleted. Database offloading is kind of the entire point of this feature, and it’s super weird that you don’t mention anywhere that we’re supposed to click that button.
Also to mention somewhere in your documentation: it’s not because a field is set to “save as single meta” that it will not get merged into the “acf” field.
I also thought the plugin was not working as expected, because it was still merging data I specifically said I wanted to keep as single meta. Not a big deal to merge it, but it should also be mentioned in your doc that this is the expected behavior. Sure it will potentially save other people lots of wasted time.
That said, great work on the plugin!

Ok so just to update that I figured a way a to do it, without deactivating the feature in the code.
Of course this will only remain until the next time that the post is saved. It’s more for debugging purposes.
1) Create a true/false acf field called “Revert single meta”
2) hook onto acf/save_post at priority 1000 (important), and manually revert each meta through update_post_meta, and not update_field (the latter will mess with repeater fields);

function my_custom_acf_process(){
//FIELDID is the corresponding FIELDID of the "Revert single meta" ACF field
    if (isset($_POST['acf']['field_FIELDID'])&& $_POST['acf']['field_FIELDID']==1){
        $_POST['acf']['field_FIELDID']=0;//Revert the true/false field;
        if (acf_is_filter_enabled('acfe/single_meta')) {//Make sure plugin and feature are active
             acf_disable_filter('acfe/single_meta');//Disable the filter
             acfe_revert_single_meta($_POST['post_ID']);//Launch the reversal
        }
    }
}
add_action('acf/save_post', 'my_custom_acf_process',1000);

function acfe_revert_single_meta($postID){
    if (!acf_is_filter_enabled('acfe/single_meta')) {
        $acfeData = get_post_meta($postID, 'acf', true);
        foreach ($acfeData as $acfKey => $acfValue) {
            update_post_meta($postID,$acfKey, $acfValue);
        }
        delete_post_meta($postID, 'acf');
    }else{
        die('acfe filter still active');
    }
}

This has nothing to do with the way the plugin is installed.
As you can see in the access.log screenshot, the error is triggered when bots try to access URIs that begin with a //
So when you do
$parsed_url = parse_url($_SERVER[‘REQUEST_URI’]);
on line 186.
If the URI begins with a double slash // (which can happen with bots),
the parse_url function will assume that the path is the host.
See this code snippet:
https://onlinephp.io?s=s7EvyCjg5VIpLco0tFXXr8jNKSpI1gOKqVtDRI2AomjCZYlF8SmluQUaBYlFxanxpUU5GmD9mjqoAkaamtYA&v=8.1.5

Addtional culprit:
Any custom js placed in the form “settings & integrations” menu

I did try it, but it led to other issues, which is why I (and many others I believe) opt for the dot “.” in the category base.
I have this code below which works just fine, I just thought that yoast could implement it for people who uses that solution.

remove_dot_yoast_schema_breakcrumb_urls($data)
{
    if (is_singular('post')){
        foreach ($data['itemListElement'] as $key => $crumbData){
            if (isset($data['itemListElement'][$key]['item'])) {
                $data['itemListElement'][$key]['item']=str_replace('/./','/',$data['itemListElement'][$key]['item']);
            }
        }
    }
    return $data;
}
add_filter('wpseo_schema_breadcrumb', 'remove_dot_yoast_schema_breakcrumb_urls');

Reopening this, since the html is still broken in 2.28
<th scope="row"><label for="sa_opacity"><?php _e('Sticky element opacity when scrolling: (optional)','sticky-menu-or-anything-on-scroll'); ?></label> <span tooltip="<?php _e('Sticky element opacity when element is sticky/scrolling','sticky-menu-or-anything-on-scroll'); ?>"><span class="dashicons dashicons-editor-help"></span></a></th>

You are still closing a span tag with an a tag lines 328,335,343,351,361,371,382,389,408,415,427,436,448,458

here’s what we came up with to get it to work:

function addCustomSitemap($gsg) {
$sitemap = new GoogleSitemapGeneratorSitemapEntry(‘my_custom_site_map.xml’);
$gsg->AddElement($sitemap);
}

add_action(‘sm_build_index’, ‘addCustomSitemap’, 100, 1);

It can’t be as it’s on a non-prod website, without any cache

Hi, no user has an account. They’re all visitors.
This WP feature is a GDPR feature, which allows anyone who left a comment to request the data we have on them. So it’s not necessarily for registered user.

Turns out the same shortcode was mapped to 2 functions haha.
sorry!