This repository was archived by the owner on Sep 24, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 142
/
Copy pathTODO.txt
132 lines (126 loc) · 9.33 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
* Next / In Progress
* Reorganize static/instance methods so that they're in normal/logical/pseudo-chronological order, rather than being grouped together
* don't separate hook callbacks based on static/non-static
* reomve isvalid and a few others?
* Add filter around $modules
* add nonces for metaboxes
* http://wp.tutsplus.com/tutorials/creative-coding/capabilities-and-nonces/
* instead of checking if $_SERVER['SCRIPT_FILENAME'] == __FILE__, check if a constant like ABSINT defined
* those two won't always match, and hard to rely on other ones too. absint is more reliable method
* Add shortcodes example
* added, but need to write unit tests
* MVC refinement
* check all functions for proper mvc separation
* make sure controllers aren't definiing data, only calling it from models
* make sure models aren't including views, only controllers do that
* make sure views aren't calling models (or API), that the controller provides data it for them?
* maybe move images,css to views dir because they're part of view
* maybe js too?
* even if that's technically correct, maybe leave in root b/c it's more practical?
* OOP refinement
* modules are tightly coupled? try to loosen?
* make module::instances protected, so that all the modules can access each other?
* or should it be private? they can use ::get_instance instead
* make $readable_properties aprt of module, and inherit?
* rename instance-class to something else?
* difference is that it's not a module, more of a standalone thing to instantiate multiple objects
* only for pure business logic classes that don't interact w/ api? and/or ones that use active record pattern?
* doesn't interact w/ api, would just be on it's own.
* maybe make a base module for singleton modules and one for instance claseses? or just ditch singleton completely and then this could inherit current module?
* cpt should be inheritence instead of interface?
* Check existing forms for nonces, check_admin_referer();
* Add data validation to user options
* Add domain-level validation (verify type, format, whitelist values, etc)
* Add validation/sanization everywhere, and nonces, current_user_can()
* Add filters to everything
* Make WPPS_Custom_Post_Type an abstract class instead of interface? It would extend WPPS_Module
* but then the cpt class couldn't define activate() etc? well, it would extend it
* example just sets up a var to define $labels, etc ?
* Move trash/untrash return checks in cpt save() to abstract class instead of interface?
* High Priority
* Add current_user_can checks to metaboxes?
* Internationalize all strings
* Change models to return a WP_Error instead of false or null, so that controllers can get a detailed error message
* Models shouldn't ever add notices, only return error to controller so it can add notice
* Throw exception if encounter unexpected condition, but return WP_Error if just need to return early
* Provide 2 examples of everything to make architecture more clear
* Add more sample classes, then add to features
* AJAX. Not really its own class, so maybe just add to CPT
* Look at BGMP and other past plugins for ideas
* Widgets. Write an interface.
* Javascript
* Add AJAX calls
* Make sure use nonces
* Example of filters/hooks once WP settles how those will be handeled (see comments on http://www.meetup.com/SeattleWordPressMeetup/events/76033072/)
* Bug - cron job not scheduled under WPMS 3.4.1, but works fine on single install. Maybe related to WPMS cron bugs, see Trac tickets.
* Add integration tests
* Things like get_post_types() and check if it's present, is_post_type_hierarchical(), etc
* Ceck that cron jobs and intervals are registered, that settings pages/sections/fields are registered, etc
* Move test suite to main tests/ dir instead of in unit sub-sir
* Fire cron job and test that it affected something
* activation/deactivation?
* When replacing "WordPress Plugin Skeleton" on installation, it also replaces the "this was built on..." notice in bootstrap.
* Change bootstrap text to avoid - replace spaces with underscores?
* Write shell script to rename
* Ship as .txt file, so user has to manually rename to .sh and execute
* Output warning to delete script after finished
* Add do_action( 'wpps_descriptive-name-before|after' ); to views so other devs can hook into them
* Capabilities requirements should use an actual capability instead of a role. Check constants, etc.
* Medium Priority
* Look through current code for best practices to add to checklist
* Bug - notices inside WordPress_Plugin_Skeleton::init() never get cleared when viewing cpt page, but they mostly do on dashboard
* Support for conditionally loading js/css
* Add to notes section for any non-standard things or anything that needs explaining
* Add exceptions. Add try/catch blocks to all hook callbooks, but nowhere else. Let them bubble up to first callback.
* Add extra error checking/handling when calling API functions (e.g., register_post_type() )
* Update Features w/ any other advantages
* Throw/catch exceptions in places. Maybe just in action/filter callbacks, since everything should bubble up to them
* CPT meta boxes - use get_current_screen() instead of global $post
* Add network-wide deactivation? Or is that done automatically?
* BGMP addFeaturedImageSupport()
* Add BGMP release checklist? Entire TODO file?
* Look for @todo's and cleanup
* Update requirements warning language. Primary concern is more about PHP 5.3 rather than PHP 5.
* Write a shell script for renaming class names, variables, etc?
* Maybe there's a way WordPress_Plugin_Skeleton->upgrade() can do settings[ 'db-version' ] = x instead of = array( 'db-version' => x );
* http://mwop.net/blog/131-Overloading-arrays-in-PHP-5.2.0.html
* Add uninstall.php
* Definte constants during init hook callback and only if they haven't already been defined, so they can be overridden easily
* http://willnorris.com/2009/06/wordpress-plugin-pet-peeve-3-not-being-extensible
* Singleton unnecessary for front controller? http://stackoverflow.com/questions/4595964/who-needs-singletons/4596323#4596323
* maybe not http://eamann.com/tech/the-case-for-singletons/. could setup reset method on singleton to clear it for testing
* cpt - support restore revisions. bug when restoring?
* change js/css to be for individual modules rather than whole plugin
* more modular and organized. could result in lots of http requests, but can concatinate/minify at runtime w/ other plugins
* js - main module calls all the individaul module's init(). main module has jquery(document).ready(), rest are agnostic
* autoload the classes directory?
* metaboxes - use get_post_custom() like bgmpvg plugin to save on sql queries. also setup getDefaultMetaFields() like it does
* convert vars, etc to underscores instead of camelcase
* replace 60 * 60 with DAY_IN_SECONDS, etc
* immediately save options to db when they change to avoid concurrency issues?
* maybe create wrapper for loading views. take rel path or maybe even pass in __CLASS__, handle output buffering when needed
* swtich cpt save to use if ( wp_is_post_autosave( $post_id ) || wp_is_post_revision( $post_id ) )
* Rename action/filter names to _ instead of -
* Change esc_attr_e() to echo esc_attr()
* Use submit_button()
* nest conditions instead of returning early. better for debugging / single point of return
* logging system to help detect errors. display to users so they can copy/paste log to plugin dev to help troubleshoot. warn about disclosing sensitive info, though, "don't post in public forums"
* unit tests for render_template()
* Low Priority
* Better singular/plural handling for custom post type names
* Maybe use a single view file for all meta boxes (within a class), rather than multiple. Switch on the box id just like the callback does.
* Add underscore to custom post meta fields, so they don't show up in Custom Fields box? See http://net.tutsplus.com/tutorials/wordpress/creating-custom-fields-for-attachments-in-wordpress/
* Use API functions in WPPS_CPT_Example::save_post() instead of accessing $post directly
* Make sure all hook callbacks have all of their parameters declared, even if you don't typically use them
* Add a status icon for each of the plugin requirements in the requirements-not-met view, so the user can easily tell which are met and which aren't
* In page settings view, you should be able to grab the title from an API function instead of manually typing it
* Clear admin notices when tearing down unit tests so that they don't show up on the next normal page load
* Add command to instructions to clear git log/history/commits etc, so that it starts fresh?
* Use {$new_status}_{$post->post_type} instead of save_post in CPTs ?
* Otherwise run into problem where save_post only fires if a core field is changed?
* Refactor the conditionals at the begining of CPTExample::save_post() so they can be reused?
* Break CPT TAG_NAME into TAG_NAME_SINGULAR and TAG_NAME_PLURAL
* validateSettigns() - force db-version to equal self::db-version? no reason why it should ever be set to anything else?
* Consider if it'd be useful to add any custom wp-cli commands, or extensions to Debug Bar or Debug This
* First time activation, valdiateSettings() adds admin notices. b/c settings don't exist in db yet? need to be primed?
* current_user_can doesn't accept a post_id argument, but trying to pass one in some places