Forum Replies Created

Viewing 15 replies - 151 through 165 (of 181 total)
  • Hey, sorry for the late reply this must have slipped past me somehow.

    Correct me if I’m wrong, but I believe the dismissed updates are for core updates when you’re running a locale other than en_US and so they do not apply to plugins.

    Plugin Author Jon Cave

    (@duck_)

    Okay, I guess then it’s just how phpMyAdmin is exporting the file and how your program displays this information (i.e. actually showing the \n instead of a newline itself). If you want to find out where abouts in the database this is you will have to look in your .sql file and look at the statements that phpMyAdmin generated (I think that’s how it exports it), to see which table the data is INSERTed into. FYI the only information Exploit Scanner puts in the database is found in the wp_options table where the option_name starts with “exploitscanner_”.

    Sounds like nothing to do with Exploit Scanner 🙂

    Plugin Author Jon Cave

    (@duck_)

    Could you clarify on where you’re seeing these entries in the database (table, column, etc.). It looks like it’s not “nwp-” but rather the newline character which is displayed as “\n” is being stored.

    The export and import have been undergoing some major maintenance. See ticket #15197 for the main details.

    Duplicated categories should be gone with with the new importer (available for download as the development version), but maybe not for old WXR export files depending on the exact problem. Exports and Imports bringing unwanted categories and tags will not be ‘fixed’ when using old export files, but the export filtering should (hopefully) be greatly improved for 3.1. Not sure what you mean by “Category exports with more than one category”, but sounds like it’s to do with export filtering again.

    Should be fixed as of 1.4.1

    Plugin Author Jon Cave

    (@duck_)

    Should be fixed as of 1.4.1

    Plugin Author Jon Cave

    (@duck_)

    Added the filter ‘updatenotifier_subject’ in 1.4.1. Example usage:

    add_filter( 'updatenotifier_subject', 'updatenote_custom_subject' );
    function updatenote_custom_subject() {
        return '[' . home_url() . '] Updates available for this WordPress site';
    }

    Place that in a file which doesn’t get modified by any updates (say a custom plugin or in a custom theme’s functions.php).

    Currently the dev version removes the back-compat induced issue described below. I am also thinking about what to do about the ‘upgrade from abc’ emails, (partial) fix to come shortly.

    Just updated the development version to fix this and it works in my testing. If you download the development version (see details above) you should see the version number as 1.4.1-beta in the Plugins menu. I would be grateful for any testing and feedback.

    Thanks.

    I have been working on some ideas to help reduce the problem. You can install the development version from this page and here is a direct link to the .zip file. Delete the installed version of Update Notifier and install the development version via Plugins -> Add New -> Upload (you will have to reconfigure your Update Notifier settings). I would be grateful if you could test it out 🙂

    Currently the dev version removes the back-compat induced issue described below. I am also thinking about what to do about the ‘upgrade from abc’ emails, (partial) fix to come shortly. Though deactivating the plugin changing the version, or stopping just the part doing the changing works for me in my testing (I have worked out why I couldn’t reproduce before, see note at the end). I have also come up with another change to these plugins which should help whilst still allowing you to leave a modified $wp_version in most situations if you so desire.

    Though I have to disagree that mangling $wp_version is useful (xref: some thoughts from a core committer) and in some cases interferes with core WordPress functions (see below about the automatic update checks made by WordPress).

    Thanks for taking the time to report and using my plugin 🙂
    – Jon

    If you’re interested here are the full details on why problems like this are occurring:

    When WordPress does its automatic check for updates it asks wordpress.org if there are versions newer than $wp_version (which in this case is ‘abc’), obviously ‘abc’ doesn’t exist and so the response is that an update is available (even if your site already has the latest version of WordPress!). This response is stored by WordPress and when Update Notifier checks this stored value it sees that, allegedly, an update available and sends an unnecessary email notification.

    Also, the problem when Update Notifier tells you that version 2.9.2 should be updated to 3.0.1 occurs because of some backwards compatibility code I had to use (because 3.0 introduced site transients for storing the automatic update check responses), so when Update Notifier looked for the stored information (when $wp_version is not correctly set as 3.0.1) it decided that you still must be running 2.9.2 and so checked the old version of the transient which says 3.0 is available (since it hasn’t been changed since updating to 3.0 and 3.0.1 because of the new transient usage).

    Note this does not occur every time since these plugins will often only modify the $wp_version global when not in the admin section. Therefore, if the automatic update check is triggered whilst an admin is logged into the backend then the correct response (no updates available, running the latest version) is stored and then Update Notifier doesn’t send an email. If the check is triggered by a normal user visiting the site then the incorrect ‘abc’ version of events occurs.

    Plugin Author Jon Cave

    (@duck_)

    Well, I’m glad it’s working, but at the same time it’s a bit annoying not to be able to find out why it didn’t originally work… oh well. If you ever have problems again in the future, please let us know here with those extra details. Thanks 🙂

    Plugin Author Jon Cave

    (@duck_)

    Do you get any JavaScript errors? Could I have a list of info such as browser, OS, and other installed plugins?

    Plugin Author Jon Cave

    (@duck_)

    Good suggestion, thanks. But instead of just adding this I will filter the subject (and maybe some other strings if it makes sense to) so that it can be customized however the site admin wants and stay customized through a plugin update.

    Plugin Author Jon Cave

    (@duck_)

    Will have a look into it.

    What version of WordPress are you running and are you using multisite?

    Thanks.

    Plugin Author Jon Cave

    (@duck_)

    Sorry for the late reply (have been away).

    Update Notifier takes data from an option saved by WordPress itself (_site_transient_update_core for core updates, similar names for plugins and themes) and should only send a core notification if the current response is ‘upgrade’. As far as I can tell, if you’re receiving emails from Update Notifier then you should also be seeing yellow update nags in the admin area (though I assume this isn’t the case). Unfortunately I am unable to replicate this problem, though will continue looking for a potential way this could happen.

    What would be useful is if I could get administrative access to an install where this is occurring (if this is not possible then I would ask for the information I would try to look at myself). Either way could you drop me an email: updatenotifier AT lionsgoroar.co.uk

    Thanks for reporting, hopefully I can sort this out.

    Plugin Author Jon Cave

    (@duck_)

    Updated with PHP 4 compability in 0.97.1, sorry for the inconvenience and thanks again for posting.

    However, it should be mentioned that PHP 4 is an end of life product and no longer supported by the PHP Group with the last security fix in 2008.

Viewing 15 replies - 151 through 165 (of 181 total)