superflyfr

Hi,

sorry the error was on our side, “something” changed the header first tab in spaces.

thank you !

• This reply was modified 4 years ago by superflyfr.

I mean : maybe you could write this somewhere on the automatisation page, around the section where we can activate the deletion of non included accounts. In the same idea, maybe add that “administrators won’t be deleted anyway” (this would relax a lot of users, I’m pretty sure – spent myself some time to add manually admins on top of my csv file !) .
Sorry for my poor English and again, thanks !

Ok, fine. That’s indeed a secure approach. Maybe you could note it on the admin panel in regard to the parameter field ? Will add a step to check emails before FTPing it. Thanks for the blazing fast answer !

Hi Javier and thank you for this great utility plugin.
I have the same issue : some users not present in the csv are still in the site user list. I do have an error regarding the import of 1 user (incorrect email address) that may hapend bc the import is based on an external site where I have no control. Could this break the whole process somehow and prevent the deleting phase ?
Note : I’m using a WP MUltisite install + scheduled import, import/update seems to work fine.

• This reply was modified 4 years ago by superflyfr.

C’mon Wordfence team; that’s barely acceptable.
You deal with the highest threats, shouldn’t be an issue to provide us a fast trick to prevent this, either with a hook or an extra param.
More widely, WF should be localized in full now; raise it on top of your roadmap please !

As of now, I had to deactivate the option “Don’t let WordPress reveal valid users in login errors”.

BTW, kudos to @leandrorocha for pointing this out, was searching for the “why” for a while, without linking it to WF : you literally saved my “life” today as we go production and my client was barking at me …

• This reply was modified 4 years, 5 months ago by superflyfr.
• This reply was modified 4 years, 5 months ago by superflyfr.

Hi Mihail,
Fair enough, this was more FTR (and a feature vote suggestion)than a real support request.

Though, the final question “is it feasible” is pre-sale related and it’ll be useful for me to get an answer.
Thanks!

• This reply was modified 5 years, 8 months ago by superflyfr.
• This reply was modified 5 years, 8 months ago by superflyfr.

Note : I could inject images via SQL query but then I’ll miss the resize, thumbs and various features that make NGG so great ??

oh, just went along @mapetek ‘s link and see the problem is here/back …

@averta_support could jump in here https://support.averta.net/en/ticket/the-server-responded-with-a-status-of-404-not-found-uploadsarray/ so that we can benefit of your fix, should it be pertinent (seems to be the same issue) ?
edit : or DM/PM me, of course.
(reg. user AntoineBapst)

• This reply was modified 5 years, 10 months ago by superflyfr.

Brilliant ! thanks @lutersmartins ??
We did have a search function where we didn’t check if it was a front-office or admin request. Lesson learned & Problem solved: get your next beer in Paris France on me !

thanks @luthersmartins
indeed, $request_type and $post_type really look weird, defined as ‘INVALID’ …
but might be defaulted as is for unknown reason (WP Core noob here).

/**
 * WP_Privacy_Requests_Table class.
 *
 * @since 4.9.6
 */
abstract class WP_Privacy_Requests_Table extends WP_List_Table {

	/**
	 * Action name for the requests this table will work with. Classes
	 * which inherit from WP_Privacy_Requests_Table should define this.
	 *
	 * Example: 'export_personal_data'.
	 *
	 * @since 4.9.6
	 *
	 * @var string $request_type Name of action.
	 */
	protected $request_type = 'INVALID';

	/**
	 * Post type to be used.
	 *
	 * @since 4.9.6
	 *
	 * @var string $post_type The post type.
	 */
	protected $post_type = 'INVALID';

	/**

• This reply was modified 6 years, 9 months ago by superflyfr.

Could a moderator please update the title so that we may read it’s GDPR (EN) / GPRD (FR) related ? We’re still stuck at this time and any hint/track would be greatly appreciated. Thanks !

• This reply was modified 6 years, 9 months ago by superflyfr.

Thanks @naveen1806 for the road map.

We identified the problem: a function in our child theme functions.php template. This function was designed to hide the WP version and I believe many users may have implemented it as such :

/* WARNING : DO NOT USE THIS - Breaks WP 4.6.9 JSON !!!*/
function hide_version() { // hide WP Version
    return '';
}
add_filter('the_generator', 'hide_version');

Replacing this function with that single line solved the problem instantly :
remove_action('wp_head', 'wp_generator');

May help some people with a similar issue (or another function that messes with the headers); was a bit difficult to identify since it never produced unwanted/side effects before (but maybe this was a bad idea since day 1 … Another copy/paste that should have been avoided: my bad, bad, bad )

• This reply was modified 6 years, 9 months ago by superflyfr.
• This reply was modified 6 years, 9 months ago by superflyfr.
• This reply was modified 6 years, 9 months ago by superflyfr.

Awesome ! Thanks a zillion times !

Edit : you deserve the 5* ??

• This reply was modified 7 years, 5 months ago by superflyfr.