You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to write down my ideas on main core architecture changes.
Obviously all core changes will be incremental and backward compatible to a degree, there is no plan or indication that we will be able to do any major rewrites in the near future.
Technical
feel free to skip
Initial refactors will remain procedural code, however the focus will be to abstract and compartmentalize where possible with the ultimate consideration of refactoring into classes and MVC structure.
Some classes may be created for core functions where applicable, such as reading and writing the asset xml files. This will encompass all actions with legacy support via wrapper functions and allow performance evaluation of all file io as well as better error handling and logging and much needed features such as file locking and even ORM abstraction. This will have a benefit of making plugins much easier to add file storage capabilities.
Editing site settings
All settings will be editable from inside the UI. GSCONFIG will remain useable, but will serve a purpose similar to an ini. Settings will all have default values if not set, and be changeable via a settings UI and saved in website.xml
Server will have settings such as timezone and locale and language added, these are essential , and some will be available to individual user accounts as well.
All server settings will be dynamic globals and not definitions.
Advanced configs for core settings will be controlled via globals or configuration.php
User accounts will be seperated from settings.
Pages
I want pages to be more generic, I would like to support things like blogs and small catalogs out of the box and allow minor customization with a simple crosspivot configuration.
Pages should be categorized, categories will be used to define what kind of page something is, they can be used or not with no effect to the end user.
And example would be categories of articles , news , videos etc.
Categories would be pre configured sets of page options or meta datas.
Categories can be added ( probably not nativley via ui, this will be a plugin or advanced configuration )
Pages would have a quick add capability, 1 button, save, possibly even in a popup, ideal for posting blogs posts or links.
Pages would be segmented by category, and possibly have custom views for them. The view of a list of articles might be a table sorted by title with several columns of useful data. A view of blog posts might be a thumbnail and excerpt sorted or grouped by dates or archive segments, months, years.
Front end function for templates would be available and categories would have extra display templates, these would include the ability to show excerpts and indexes of a category on a category page. These templates might be default or customized or simply category components.
A category might map to default component for index display.
I want all this functionality accomplished via the addition of only a few front facing configurations. This has to remain simple, but provide the framework for plugins to enhance them or an advanced user to write custom components for them.
With the configuration of page-types or categories, almost any variation of management can be accomplished. Traditonal pages, blog posts, media objects, small catalogs of items or software, design portfolios.
This may require the addition of a core library to generate inputs and process posted data to xml files, but can be handled fairly easy and even automatically with simple templates to designate ids, type of input, its data mask, validation, post processing callouts. This part would be similar to how some plugins work like special pages, custom fields, dm_matrix, but without the UI builders.
Pages will also get some additional fields as already discussed elsewhere.
Asset Editing and programming
Themes
The theme editor is lacking, it has already been replaced in 3.4 with a nice ajax themeable updated codemirror and file browser I wrote, I would like to expand this editor to be the default editor for everything. Components will be individually edited just as theme files would be, but instead of a file tree it will be a list of components.
Themes will also have a config page available somehow to configure theme settings, it will likely simply be a placeholder for themes to add a form and get settings back , capability for storing and loading settings may be added to core to assist theme designers.
Components/Snippets
Components will also be expanded to be toggleable on and off, and in different flavors, "snippets" will be html only components and offer a wysiwyg editor instead of a code editor.
Components will be backwards compatible but have the ability to load components from files, this will allow distributable components, and themes and plugins to add components easily.
Components will also be able to be registered dynamically from plugins or themes.
Core components insertion, like dyn-pages plugin, add component shortcodes to core, and an inline insertion dropdown in ckeditor.
Uploads and Media Assets
Uploader
The file manager will possible be updated to support better file management, renaming, moving, better previewing etc.
The upload methods will all be removed and replaced with new one. Uploadify will go away, a single upload library will be used that support html5 ajax uploads, drag and drop, and mobile uploading.
Image Manipulation
A new image library will replace the 3 different ones we have now, everything will tie into it, this will possible break some stuff, but we will try to make stuff like thumbs.php continue to work as expected. New image library must support easy OOP based configuration for many image operations.
This library will provide plugin authors the ability to do any image manipulation they might need such as watermarking and conversions, Advanced thumbnail creation and auto resize by max filesize and much more.
Eventually this may be replaced with a cross image library that can use gd or imagemagick, but this is a ways down the road when we drop php 5.2 support. But considerations might be made by using our own abstraction to help with backwards compatibility for this.
Thumbnails
Thumbnail creation will be improved with many cropping features, namely the most common presets. eg. Auto fit via crop center, left, or right, or fill, for consistent sized thumbnails.
New options for manual creation ( using our UI image.php and jcrop ), such as crop and fit.
Site wide thumbnail settings will be added to Settings UI. Default thumb size, and cropping mechanism.
May be somehow tied into page categories, or categories have their own thumb settings and image attachers.
Menus
A new menu editor based on sortable hierarchies, combined with new template functions and a menu cache or adjacency list will offer the ability for multiple custom and multi level advanced menus
Plugins
Plugins will have some new features, ability to register dependencies, we can indicate this in plugins panel and offer warnings.
Plugins will be able to register assets such as help documentation, links, and configuration links, this will be the preferred way to configure plugins so they are not adding side menus all over the place for simple settings.
One click automatic updating would be very nice also, but will have to have reversion capability.
Content Editing
Make code and wysiwyg editors global, can be added anywhere with simple classes.
Make editors pluggable, hooks to insert your own editors, lightweight html5 and markdown would be awesome in core.
I wanted to write down my ideas on main core architecture changes.
Obviously all core changes will be incremental and backward compatible to a degree, there is no plan or indication that we will be able to do any major rewrites in the near future.
Technical
feel free to skip
Initial refactors will remain procedural code, however the focus will be to abstract and compartmentalize where possible with the ultimate consideration of refactoring into classes and MVC structure.
Some classes may be created for core functions where applicable, such as reading and writing the asset xml files. This will encompass all actions with legacy support via wrapper functions and allow performance evaluation of all file io as well as better error handling and logging and much needed features such as file locking and even ORM abstraction. This will have a benefit of making plugins much easier to add file storage capabilities.
Editing site settings
All settings will be editable from inside the UI. GSCONFIG will remain useable, but will serve a purpose similar to an ini. Settings will all have default values if not set, and be changeable via a settings UI and saved in website.xml
Server will have settings such as timezone and locale and language added, these are essential , and some will be available to individual user accounts as well.
All server settings will be dynamic globals and not definitions.
Advanced configs for core settings will be controlled via globals or configuration.php
User accounts will be seperated from settings.
Pages
I want pages to be more generic, I would like to support things like blogs and small catalogs out of the box and allow minor customization with a simple crosspivot configuration.
Pages should be categorized, categories will be used to define what kind of page something is, they can be used or not with no effect to the end user.
And example would be categories of
articles,news,videosetc.Categories would be pre configured sets of page options or meta datas.
Categories can be added ( probably not nativley via ui, this will be a plugin or advanced configuration )
Pages would have a quick add capability, 1 button, save, possibly even in a popup, ideal for posting blogs posts or links.
Pages would be segmented by category, and possibly have custom views for them. The view of a list of articles might be a table sorted by title with several columns of useful data. A view of blog posts might be a thumbnail and excerpt sorted or grouped by dates or archive segments, months, years.
Front end function for templates would be available and categories would have extra display templates, these would include the ability to show excerpts and indexes of a category on a category page. These templates might be default or customized or simply category components.
A category might map to default component for index display.
I want all this functionality accomplished via the addition of only a few front facing configurations. This has to remain simple, but provide the framework for plugins to enhance them or an advanced user to write custom components for them.
With the configuration of page-types or categories, almost any variation of management can be accomplished. Traditonal pages, blog posts, media objects, small catalogs of items or software, design portfolios.
This may require the addition of a core library to generate inputs and process posted data to xml files, but can be handled fairly easy and even automatically with simple templates to designate ids, type of input, its data mask, validation, post processing callouts. This part would be similar to how some plugins work like special pages, custom fields, dm_matrix, but without the UI builders.
Pages will also get some additional fields as already discussed elsewhere.
Asset Editing and programming
Themes
The theme editor is lacking, it has already been replaced in 3.4 with a nice ajax themeable updated codemirror and file browser I wrote, I would like to expand this editor to be the default editor for everything. Components will be individually edited just as theme files would be, but instead of a file tree it will be a list of components.
Themes will also have a config page available somehow to configure theme settings, it will likely simply be a placeholder for themes to add a form and get settings back , capability for storing and loading settings may be added to core to assist theme designers.
Components/Snippets
Components will also be expanded to be toggleable on and off, and in different flavors, "snippets" will be html only components and offer a wysiwyg editor instead of a code editor.
Components will be backwards compatible but have the ability to load components from files, this will allow distributable components, and themes and plugins to add components easily.
Components will also be able to be registered dynamically from plugins or themes.
Core components insertion, like dyn-pages plugin, add component shortcodes to core, and an inline insertion dropdown in ckeditor.
Uploads and Media Assets
Uploader
The file manager will possible be updated to support better file management, renaming, moving, better previewing etc.
The upload methods will all be removed and replaced with new one. Uploadify will go away, a single upload library will be used that support html5 ajax uploads, drag and drop, and mobile uploading.
Image Manipulation
A new image library will replace the 3 different ones we have now, everything will tie into it, this will possible break some stuff, but we will try to make stuff like thumbs.php continue to work as expected. New image library must support easy OOP based configuration for many image operations.
This library will provide plugin authors the ability to do any image manipulation they might need such as watermarking and conversions, Advanced thumbnail creation and auto resize by max filesize and much more.
Eventually this may be replaced with a cross image library that can use gd or imagemagick, but this is a ways down the road when we drop php 5.2 support. But considerations might be made by using our own abstraction to help with backwards compatibility for this.
Thumbnails
Thumbnail creation will be improved with many cropping features, namely the most common presets. eg. Auto fit via crop center, left, or right, or fill, for consistent sized thumbnails.
New options for manual creation ( using our UI image.php and jcrop ), such as crop and fit.
Site wide thumbnail settings will be added to Settings UI. Default thumb size, and cropping mechanism.
May be somehow tied into page categories, or categories have their own thumb settings and image attachers.
Menus
A new menu editor based on sortable hierarchies, combined with new template functions and a menu cache or adjacency list will offer the ability for multiple custom and multi level advanced menus
Plugins
Plugins will have some new features, ability to register dependencies, we can indicate this in plugins panel and offer warnings.
Plugins will be able to register assets such as help documentation, links, and configuration links, this will be the preferred way to configure plugins so they are not adding side menus all over the place for simple settings.
One click automatic updating would be very nice also, but will have to have reversion capability.
Content Editing
Make code and wysiwyg editors global, can be added anywhere with simple classes.
Make editors pluggable, hooks to insert your own editors, lightweight html5 and markdown would be awesome in core.
Bundled Plugins
See #1188
The text was updated successfully, but these errors were encountered: