Skip to content
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

Default WP_List_Table Styles Rule for UI Improvement #227

Merged
merged 1 commit into from Oct 30, 2014
Merged

Default WP_List_Table Styles Rule for UI Improvement #227

merged 1 commit into from Oct 30, 2014

Conversation

shivapoudel
Copy link
Contributor

Since TGMPA_List_Table is hijacking and extending WP_List_Table which is private class and is Limited for core usage only. Similary, we are utilizing similar plural args of WP_Plugins_List_Table too. Means we are adding plugins page style rules directly from the core plugins page and our table <thead> and <tfoot> checkbox are not well managed as well as other css stuffs. Thus let's be smart and accept default WP_List_Table styles rather than Plugins Page.

/**
 * Confidential Information!
 * WP_Plugins_List_Table is already utilizing 'plural' => 'plugins'
 * Let's be smart dudes and use only singular args :)
 */
parent::__construct( array(
    'plural' => 'plugins',
    'screen' => isset( $args['screen'] ) ? $args['screen'] : null,
) );

@shivapoudel shivapoudel changed the title Default WP_List_Table Styles Rules for UI Improvement Default WP_List_Table Style Rules for UI Improvement Sep 24, 2014
@shivapoudel shivapoudel changed the title Default WP_List_Table Style Rules for UI Improvement Default WP_List_Table Styles Rule for UI Improvement Sep 24, 2014
@shivapoudel
Copy link
Contributor Author

This Changes <table class=".......... plugins"> to <table class="........ plugin">
image 1

@shivapoudel
Copy link
Contributor Author

@GaryJones could you look for this PR.

GaryJones added a commit that referenced this pull request Oct 30, 2014
Default WP_List_Table Styles Rule for UI Improvement
@GaryJones GaryJones merged commit a105c92 into TGMPA:develop Oct 30, 2014
@shivapoudel shivapoudel deleted the develop branch October 30, 2014 05:29
@shivapoudel
Copy link
Contributor Author

@thomasgriffin and @GaryJones can this be commited for master and othe 3.0.0 branch too ;)

@jrfnl
Copy link
Contributor

jrfnl commented Apr 21, 2015

@shivapoudel It will definitely be included in the 3.0 branch, not to worry (not sure about master).

@shivapoudel
Copy link
Contributor Author

Cool! When is the release date?

@jrfnl
Copy link
Contributor

jrfnl commented Apr 21, 2015

@shivapoudel eh... when it's ready... ;-)

@GaryJones
Copy link
Member

It won't be in 2.4.1 but it will be in 2.5.0

@GaryJones GaryJones added this to the 2.5.0 milestone Apr 21, 2015
jrfnl added a commit that referenced this pull request Apr 28, 2015
- retrieve most information we need from our `$plugins` array rather than pass it through URL or $_POST
- properly sanitize and validate received information from URL or $_POST
- leverage the use of the WP_filesystem API
- show an appropriate error message if user tries to activate an already active plugin
- deprecate the `TGMPA_List_Table::_get_plugin_data_from_name()` method which is no longer needed as we have access to the `TGM_Plugin_Activation::_get_plugin_data_from_name()` method
- Fix unauthorized issue on bulk installs when not using direct file access caused by #227
- Only prepare some variables and update recently activated plugins option when we actually need to

Also:
- abstract the regexes which are used a number of times to class constants
- combine multiple `isset()`'s if used within the same if statement
- don't nest what doesn't need nesting
- unset loop variables if the function doesn't return straight after
jrfnl added a commit that referenced this pull request May 3, 2015
Most significant changes:
- added views: 'to install', 'update available', 'to activate'
- simplified the `_gather_plugin_data()` method by abstracting parts of it to separate methods
- reverted the change to the constructor arguments from PR #227 as that breaks things, instead overload the `get_table_classes()` method which archives the same effect as PR #227 intended
- added 'version' column and a method to generate the output for it
- made column to display dependent on the chosen view
- abstracted the plugin row actions to a separate method
- made the row actions always visible (was on hover), similar to the WP native plugins table
- added upgrade notice information to a plugin row if available
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants