Unify plugin update notices and include changelog data

[dempsey]

Currently the after_plugin_row hook is only used on plugins.php which is used by the Changelogger plugin to show plugin changelogs inline.

If the hook is also added to the bottom of list_plugin_updates in update_core.php then changelogs could also be displayed on that page too.

It's only a single line change so not sure how/if it's worth me attaching a patch for this?

[scribu]

Yes, it would be worth attaching a patch, but I don't think naming the hook 'after_plugin_row' is a good idea. That hook is meant for the plugins page and can be used for other things besides showing changelogs.

[dempsey]

Proposed patch.

[dempsey]

I've added a patch with the proposed action names of after_plugin_updates_row and after_theme_updates_row

[nacin]

Good start. Going to try to standardize some things here. Aside from this, the update notices should also appear on plugins.php.

[Alphawolf]

Cool.

I am the author of the Changelogger plugin and adding that hook would be a huge improvement for the plugin to show information before an (plugin) update process.

Thanks for suggesting, dempsey!

[nacin]

Shifting this to a task.

Let's plan to pull in the update notices to plugins.php and bring Changelogger into core. Initial patches welcome. The idea would be that we can show a changelog not just before updating, but after as well (probably on the upgrade screen itself). If a changelog was too long, we'd have a way to collapse it. I might end up re-using the plugins list table here.

I'm tempted to split off how we handle DISALLOW_FILE_MODS as well. Right now, that kills update_* caps, but I think a better use case would be this: you want to manage your stuff via Subversion, but wouldn't mind seeing the notices if you can otherwise -- you just don't want to allow the notices to appear. Currently, everything gets blocked out, which might make sense if someone was maintaining an install for a client, but if that were the case, they'd possibly just hide the Plugins screen anyway. DISALLOW_FILE_MODS should handle security implications, not notification ones. Ryan, thoughts?

[jane]

Punting because we are at freeze and there's not a patch ready for commit. Revisit early 3.4.

[sirzooro]

3.4 has just started, so please take a look on this :)

[dempsey]

Any chance of getting this into 3.5? What needs doing?

[dempsey]

How about into 3.6 as we're in the early stages? What needs to be done?

[SergeyBiryukov]

I guess comment:7 summarizes what needs to be done.

[chriscct7]

@nacin Did you still want to merge Changelogger?

[stephenharris]

Add upgrade notice to plugins page