Alan Fuller

you can look in .htaccess maybe

Changing the admin URL is not a standard feature, so I’m surprised you say it wasn’t via a plugin. The fact you got an email even more so.

if I were you, I’d take a backup of your site from your control panel, and then do the plugin directory rename but also see if you have an mu-plugin directory ( as some hosts add that without you knowing )

How did you change it? Did you use a plugin like ‘Hide my Admin’? If so vi aftp go the wp-content/plugins and rename ( not delete ) the plugins folder e.g. plugins-old then login all plugins will be deactivated. Then rename the folde rback to plugins , go to teh plugins page and the recently active tab and re-activate them. ( then go the the admin hide plugin and rename it to something you can remember )

Yes, that is all gone now.

I would suspect, as that version I mentioned I was thinking of commercializing to support it, it had the Freemius library and they probably didn’t want to expose to subsite users the ‘upgrade’ link, or something like that.

I would add, if you are at all concerned then best to update on a staging or development copy first, especially if you are updating a site that has not been updated a while and is changing major WP versions.

At the very least make sure you have a good backup.

1.3.20 is a very old version and include( and out of date version of) the Fremius library which may be the root of your issue as it does funly things, this was back when I thought I might create a premium version.

The current version does not contain any libraries.

The composer.json exists in the code as part of the build process and as required by www.remarpro.com build toold need to be included, but there is no link to the update process it is just there.

( I did notice that the WordPress SVN copy of composer.json is out of sync with the master on github, that will need fixing but it is not material as it is not used in WP )

syslog( LOG_INFO, esc_html( "Attempted user enumeration from " . $ip ) );

this will log to whatever your syslog is.

If you are testing make sure you are logged out as it deliberately doesn’t stop enumeration of authorised users.

I’m glad that seems to sort it .

@gpguy please start your own thread, this is considered best practice, for several reasons, your issue may look the same but very often the cause is different and the visibiliy on old threads is very limited to those that participated but a new thread will have many eyes looking.

Not sure closed plugins can be hijacked as the slug is never released.

Reporting on closed plugins 2 weeks before 6.6 is just noise. In other times it is a low priority information that a plugin will no longer be actively supported.

As mentioned, authors can not comment on closure reasons. The plugin repo does not report the reason for security reasons as explained and authors are expected to do the same.

The only calming measure is for the plugin authors to work with the plugins team to get the plugin re opened as soon as they can.

I know that does not help much, but the free plugin directory is managed in that way to be on the best interests of the community that uses the plugin contributions.

here is the issue, you can’t and shouldn’t acknowledge publicly.

Why, because if you acknowledge it is not a security issue this time, but next time it is a security issue and so you can’t acknowledge without giving hackers a heads up but deduction then not acknowledgement implies a security issue giving hackers heads up.

WordFence creating noise is a Wordfence issue.

If they are reporting things just because they are closed without a security CVE then they are reporting something that means nothing.

To be clear, when there is a new release plugin authors are emailed. If their email bounces their plugin is temporarily closed.

so yes this happens a lot about 2 weeks before a point release.

I am not a commiter, not related to Mailgun so I can’t help, you I just contributed a small fix once as it is open source software and they rightly acknowledged my contribution.

Personally I not longer use this plugin for different reasons and use one of the alternatives.

When a plugin is closed there can be many reasons, but at this time of year just before 6.6 release any plugin emails that bounce get their plugins closed. Whilst impossible to rule out other reasons such as security, the balance of probabilities is it is the commiter email bouncing. Ironic really.

I can’t really give you examples on how to code contributions but to contribute you can fork https://github.com/alanef/quick-event-manager and if you get a working solution that has some flexibility you can create a pull request to consider merging

The main function to look at is get_event_calendar_icon ( starts line 369 ) and around the else in 482 – warning it is complex so I’d recommend adding a filter and then applying your logic external to the plugin.

https://github.com/alanef/quick-event-manager/blob/master/legacy/qem-event-build-functions.php#L369