#9532 closed enhancement (fixed)
Get the readme.txt metadata
Reported by: | Txanny | Owned by: | |
---|---|---|---|
Milestone: | 2.9 | Priority: | normal |
Severity: | normal | Version: | 2.7.1 |
Component: | Plugins | Keywords: | |
Focuses: | Cc: |
Description
Some times we need to know some more information about the plugin that provided by plugin metadata: This in the header of the plugin file and read with get_plugin_data().
Specially, the most interesting data located at the readme.txt file, is the 'Required WordPress Version'.
A function to get this information would be really needed if we want to check the Required WordPress or get the link to the donations page.
I attached here a patch with the function to be included in the wp-admin/includes/plugin.php file. I've been using this function for a while, so it is well tested.
Attachments (2)
Change History (17)
#1
@
16 years ago
Better yet, this information should be used to automatically disable invalid plugins on WP upgrades.
#2
@
16 years ago
This is the normal way I use it. If the required version does not met, then I set an admin warning and do not load any functionality. This way the plugin does not crashes any "incompatible" WordPress blog.
#3
@
16 years ago
- Keywords needs-patch added; has-patch tested removed
- Milestone changed from 2.8 to Future Release
patch fails in today's trunk
#5
@
15 years ago
- Keywords has-patch tested commit added; needs-patch removed
- Milestone changed from Future Release to 2.8
new patch is refreshed against 11300 and takes care of returning false on failure
#6
@
15 years ago
Seems what is really needed (regarding version compatibility) is a change to the plugin update notification so that if you're using WP 2.7 and a plugin requires WP 2.8 minimum, you don't get the update notice. (Or a modified notice...?)
The example you give requires a plugin author to specify a *max* compatible WP version, which exists but is far less common. For that case, patch #8964 would work.
So... there may be cases when you want to pull readme data, but the example you give does not warrant committing this patch, IMO.
#8
@
15 years ago
Imo, the fields should be used by WP, as early as 2.9.
The required field should be used to prevent the activation of a plugin that won't work. And the tested up to field should a) be used to deactivate the plugin before core upgrades and b) pass a warning (using js, for instance) when the user tries to activate it.
#9
@
15 years ago
- Keywords early added
- Milestone changed from 2.8 to 2.9
punting, due to manifest lack of interest
#11
follow-up:
↓ 12
@
15 years ago
- Keywords needs-patch added; has-patch tested commit early removed
- Milestone changed from 2.9 to Future Release
You should be able to do this from your plugin using the new get_file_data function now available in trunk.
Not sure we need a readme file specific function.
Moving to Future Release for now.
#12
in reply to:
↑ 11
@
15 years ago
- Keywords close added
Replying to westi:
You should be able to do this from your plugin using the new get_file_data function now available in trunk.
Not sure we need a readme file specific function.
Moving to Future Release for now.
suggesting we close as fixed. get_file_data() seems it should get the job done.
#14
@
14 years ago
- Keywords needs-patch close removed
- Resolution set to fixed
- Status changed from new to closed
This is now somehow possible by passing the Metadata Header Fields in the form of an array to get_file_data() now (untested example code):
$default = array( 'Contributors', 'Donate link', 'Tags', 'Requires at least', 'Tested up to', 'Stable tag' ); $default = array_combine($default, $default); // w/o key this does not work $data = get_file_data('readme.txt', $default); print( 'Contributors' . $data[Contributors] );
I think when this ticket was created get_file_data() did not exist or was in parallel or was just very new (#8964 / [12044]). I'll close this ticket now because some adequate functions that works for this case exists today (just tested it in a plugin of my own). Feel free to re-open if you see fit.
Additionally there is another suggestion to make everything File Header related more modular. That's the related ticket I just linked in my previous comment.