-
Notifications
You must be signed in to change notification settings - Fork 805
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON API: Add new action_links
field to plugins endpoint
#6267
Conversation
The only way to get the links in an HTML tag format, so this parses out the url and link name and returns them in an array.
protected function get_plugin_action_links( $plugin_file ) { | ||
$formatted_action_links = array(); | ||
|
||
$action_links = apply_filters( 'plugin_action_links', null, $plugin_file, null, 'all' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a docblock here? Something like /** This filter is documented in src/wp-admin/includes/class-wp-plugins-list-table.php */
should work and will make our parser happier.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added exactly that in 309f823
I wasn't sure about API tests for Jetpack endpoints, do we still run them from wp.com? |
Why not use the full url instead of relying on a partial url? |
I've realized this isn't working so well because most plugins will hook into |
… action links. Could be scary for a number of reasons including performance of the endpoint. Also run the new plugin_actoin_links filter that keys on the filename of the plugin.
I've got a solution working to capture the links, but it requires performing the If anyone has attempted something like this before, please let me know how crazy this is :) |
I added support for this in 7944833 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works well. I'm sorry it took me so long to review.
I cannot think of a way to get action_links
without calling admin_init
.
I'm quite concerned about this though as it seems like not a very "normal" WordPress thing to do.
Perhaps not, but it does make sense if you think about it. With this endpoint, we are exposing a list of plugins and their meta data, information which is only available in wp-admin.
I do appreciate you considering performance, but as you said, many plugins will hook to admin_init to provide this information, and we would be excluding them.
Also, we should probably add the same action_link
field to the endpoint for a single plugin: /sites/$site/plugins/jetpack%2Fjetpack
for example.
Not sure when the next beta is going out, but for Automated Transfer's sake it'd be great to get this API merged soon. |
@roundhill The Beta will be available next week. We'll see about reviewing this PR and merging it until then! 👍 |
LGTM. Can't speak to performance much, but given that we seem to be stuck running |
/** This filter is documented in src/wp-admin/includes/class-wp-plugins-list-table.php */ | ||
$action_links = apply_filters( "plugin_action_links_{$plugin_file}", $action_links, $plugin_file, null, 'all' ); | ||
if ( count( $action_links ) > 0 ) { | ||
$dom_doc = new DOMDocument; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, I love seeing documents parsed with DOMDocument
, but the problem is that sometimes it may be unavailable if the XML module is disabled. While it's probably a rather small edge case, it would cause a fatal for the whole endpoint response. What do you think can be done about it? I'd hate to resort to regex parsing in that case, can we just omit action links in case DOMDocument isn't available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it's not the end of the world if we can't get the links for sites with the XML module disabled. Would a try/catch be appropriate here to check that DOMDocument
is available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I don't think we have any means of knowing that percentage. My hope is that it will only affect sites that are running on manually configured servers. Thanks for adding that change!
* Changelog: update stable tag and move changelog to changelog.txt Also remove old releases from readme.txt to keep the changelog tab short. * Changelog: add #5883 Also update the filter's docblock to match new version. * Changelog: add #5938 * Changelog: add #6298 * Changelog: add #3405 * Changelog: add #5941 * Changelog: add #6239 * Changelog: add #6281 * Changelog: add #6303 * Changelog: add #6018 * Changelog: add #6300 * Changelog: add #6296 * Changelog: add #6130 * Changelog: add #6292 * Readme: remove extra "on". * Changelog: add #6307 * Changelog: add #3297 * Changelog: add #6275 * Changelog: add #6321 * Changelog: add #6297 * Readme: update the support forum link anchor. Anchor changed when WordPress.org forums were updated to bbPress 2 * Readme: update list of a12s, it wasn't up to date anymore! * Changelog: add #6338 * Changelog: add #6337 * Changelog: add #6335 * Changelog: add #6333 * Testing List: first version of the 4.7 testing list. * Changelog: add #6332 * Changelog: add #6325 * Changelog: add #6326 * Changelog: add #6339 * Changelog: add #6342 * Changelog: add #6343 * Changelog: add #6346 * Changelog: add #6347 * Changelog: add #6279 * Changelog: add #6306 * Changelog: add #6312 * Changelog: add #6316 * Changelog: add #6171 * Changelog: add #6317 * Changelog: add #6246 * Changelog: add #6263 * Changelog: add #4220 * Changelog: add #5888 * Changelog: add #3406 * Changelog: add #3637 * Changelog: add #6320 * Changelog: add #5992 * Changelog: add #6322 * Changelog: add #6324 * Changelog: add #6352 * Changelog: add #6355 * Changelog: add #6360 * Changelog: add #6362 * Changelog: add #6369, #6382 * Changelog: add #6370 * Changelog: add #6375 * Changelog: add #6383 * Changelog: add #6384 * Changelog: add #6386 * Changelog: add #6395 * Changelog: add #6403 * Changelog: add #6406 * Changelog: add #6418 * Changelog: add #6419 * Changelog: add #6434 * Changelog: add #6446 * Changelog: add #6006 * Changelog: add #6096 * Changelog: add #6399 * Changelog: fix typo. @see #6331 (comment) * Changelog: add #6440 * Changelog: add #6443 * Changelog: add #6445 * Changelog: add #6463 * Changelog: add #6468 * Changelog: add #6471 * Changelog: add #6474 * Changelog: add #6480 * Changelog: add #6497 * Changelog: add #6499 * Changelog: add #6514 * Changelog: add #6267 * Changelog: add #5940 * Changelog: add #6492 * Changelog: add #5281 * Changelog: add #6327 * Changelog: add #6451 * Changelog: add #6525 * Changelog: add #6530
… and #6267 Merges r151791-wpcom.
Over in Automattic/wp-calypso#82 we'd like to show any action links that the plugin uses in the Calypso plugins page. This PR adds support for returning these action links via the
/sites/example.com/plugins
endpoint.The only way to get the links is in an HTML tag format, so this parses out the url and link name and returns them in an array. Because the plugin developer can return anything they want in these links, I used
DOMDocument
to handle the parsing to be safest. Other ideas are welcome!To test
D4247
to your wp.com sandbox to whitelist the new field.get
to the/sites/your-jetpack-dev-site/plugins
endpoint.action_link
array if no action links were added, or an array of data if it exists for the plugin: