Milestone 0.4

Milestone 0.4

Here are some of the current ideas in store for 0.4, and given that this version is a subversion update (0.X^.0), it is likely to include a database update (DB^), and/or may have some major altercations. With that in mind, always back-up data and report issues immediately, and if interested in testing development there is the option to download the Dev Branch.

• Core/General
  • Improved Error handling.
• (Internal) Shortcodes
  • Redesign into a Class/Object with shortcode functions.
    • Handles replacing List_Content.
    • Isolate (internal) shortcodes to Call instance.
  • Improve shortcode params RegEx to handle attributes in any order, OR use wp shortcode api for better variable handling and regex replacing (stripping shortcode).
  • 1* Preset [post_list] (General Global Setting?). Note: Default display nothing.
• Filter
  • Create Class APL_Filter. DB^
  • Time & Date preset settings?. DB^
• Design
  • Create Class APL_Design. #9 DB^
• Change APLPresetObj and/or APLPresetDbObj to save ID names for Filter and Design. DB^
  • [Prep]Move Filter & Design settings to separate Objects/Classes.
• Extension Support
  • Allows custom functionality for others.
  • Custom Filter Hook
  • Inject 3rd party plugins (bbPress)& API (Social media)
  • Multi Layout support for Admin UI
• [Prep] Internalization & Localization (Translation Support). #6

Front-end UI

• General Design/Style UI
  • Follow WP's Default Style.
  • Redesign Before, Content, & After to hide Before & After.
    • Hide/Enable Exit Message.
  • Hide & show post_types on demand.
• Admin Dashboard Side Menu UI. #10
  • Create WP Dashboard Side Menu.
    • Dashboard
    • Database (All Presets)
      • All/Presets
    • Add New
      • Preview
    • General Setting

(Internal Shortcodes)

This would mark the last of the original code from Kalin's Post List, which he also further contributed to, but as planned, the code will get a regrade. This is more for backend purposes, but will also improve further development. Some other improvements would include encapsulation, OOP, and opening up the possibility to Hooked Shortcodes.

The shortcodes are intended to be “Internal”(mainly to prevent conflicts), and 0.3 still provides that implementation, but uses a PHP RegEx Callback function. The idea functions well except for a few minor bugs that could be fixed, but requires a complicated method. WordPress provides a Shortcode API concept which 0.4 will be implementing by using a class to construct/destroy, replace preset content, and keeps shortcodes isolated to its own function. In turn provides a better algorithm, object handling, and variable params.

Implementation (Dev Notes)

Create/Use a Class Object - Add a new Class/Object for these shortcodes (APLShortcodes), and combine APLCallback Class since the two are relative. Enhance shortcode params RegEx - Currently, params used in internal shortcodes are read from beginning to end. Meaning if you need to use a param, you have to write the prior params first before adding the param needed.

OR

Use Shortcode API which will find the shortcode(s) via RegEx, do_shortcode, and handle the (improved) variables.

Filter

This is more for development purposes to stage for further releases than it is any noticeable difference (Same with APL_Design). The purpose is to take user friendly data, and turn it into WP friendly data as much as possible. So when the filter is active, it has as minimal amount of processes as possible. It also eliminates having to use objects that are fairly nested with more objects and arrays. Which is both confusing and has been error prone at times.

Design

This will create a new object/class to handle majority of the functionality of preset designs. Much like APL_Filter, the differences will be very subtle, if at all, but also has a place in mind for further development. Majority of the differences will be noticed within the shortcode functionality, which this class will primarily be handling, and is further explained under (Internal) Shortcodes.

Admin UI/Menu

The process of creating preset post_lists will feel relatively the same, but may be more minimal/layered at first-sight compared to an overwhelming amount of information initially being displayed. The idea is to hide what doesn’t ‘need’ to be shown. All the same settings will be available

The post types and taxonomy will also display only what is needed depending on what post_types to use (and taxonomies, but may need some rework on the backend. Note: Keep in mind default values if users don’t select anything. Use WP Defaults, add everything, or display nothing? Using an ‘All’ terms in Categories is the current idea since WP requires all posts within that post type to use a term.