Code Revisions 0.8

My Google Summer of Code project at WordPress, Code Revisions, finally is available in the WordPress.org plugin repository. It is not final yet, but close to. The whole development process was and still is accompanied by weekly posts on make/core. Features and bugs are kept track of on the WordPress gsoc trac. If you find a bug don’t hesitate to report it there.

Go get it: http://wordpress.org/plugins/code-revisions/

Theme and plugin dependencies

Currently I have two child themes in the making. I basically really like the parent themes and only change minor things about them for my own use cases. When thinking about releasing one of them to the WordPress.org theme repository I already started coding a class for automatically installing  the parent theme on activation. I did not finish the script because I realized that broken themes are not allowed to run any code. Child themes without parent themes are obviously broken to WordPress.

Some themes already prompt users to install certain plugins when activated. WordPress just is what it is today because it can be enhanced with thousands of themes and plugins. Therefore I think adding dependency functionality to core is indispensable.

There are multiple ways to realize this. Child themes are dependent on parent themes. Themes can be dependent on plugins. Also plugins might enhance functionality of other plugins. My approach to this would be to introduce a new header parameter (in style.css / my-plugin.php) for dependencies: ‚plugins‚. Furthermore the ‚template‚ header might in the future also be usable in plugins. ‚plugins‚ and ‚template‚ (latter only changes for plugins) not only can include a single plugin/theme slug but multiple. Separation would be realized using commas ( , ) for ‚and‘ and semicolons ( ; ) for ‚or‘. The or is only required if we want to add give plugin authors the ability to restrict their plugins to specific themes. I am not sure if this is a good idea. This definitely needs discussion.

A problem with using slugs for „template“ and „plugin“ headers when referring to the *.org repository: Slugs are not required to be unique. So some convention would be required here. The repository uses unique URLs and this functionality could rely on the last part of it: „http://wordpress.org/extend/plugins/my-plugin-2„. Also full URLs to a zip package could be imaginable but might result in a security flaw.

With the new functionality installing a theme with dependencies would be a little different:

After activating a child-theme with missing template/parent theme the user would no longer just be prompted about its brokenness but would directly be able to install the parent theme easily: A link in an admin notice brings up the WordPress.org thickbox like when installing themes manually. Two-click installation.

Same for themes which depend on plugins: Prompt the user with a link which brings up the thickbox for easy installation. When multiple plugins are required we could also provide a „directly install all“-link which does not require opening multiple thickboxes.

I think I am more than capable of realising this project. Same as with my other two proposals: I do not have any specific request regarding a mentor. Someone with knowledge of the interaction between WordPress installs and WordPress.org would be pretty useful. Knowledge of how WordPress handles theme/plugin activations etc would be a benefit as well. Otto might be perfect for mentoring this, but I think he is not available for mentoring. Andrew suggested the idea, so maybe he might be interested in mentoring it himself?

Would like some feedback here! GSoC proposal time is running out. I hope to get in 🙂

Widget Collections Reconsidered

After finally getting at least some feedback to the original idea for my Google Summer of Code project, Widget Collections, I review it in this post.

I still stick to the initial problem: When changing themes the widget setup is often lost and at the moment there is no way to avoid reassigning widgets one by one to the new sidebars.

My original approach was to introduce a new WordPress core feature called „Widget Collections“. The idea was to be able to group widgets in collections and assign them to the sidebars in groups. These collections won’t be lost when the theme is changed, which would make it simple to reassign them. While collections might be useful to some users who often change their widget setups they would for most users just add complexity.

The new approach is all about not adding complexity to core while still enhancing the experience. It consists of two parts: An unobtrusive layout for the user to migrate the old sidebars and their widgets to the new and enhanced auto reassigning in the background.

new-theme-activated

WordPress will remember the old widget setup and the first time widgets.php is visited after a theme change the user will be prompted to migrate the old widgets. Here I have got two different ideas which need to be discussed: Either an overlay or own widgets-migrate page which fills the whole admin content wrap. This would contain a new interface: Old sidebars on the left, new on the right. Move widgets or whole sidebars from the left to a sidebar on the right for migration.  The user can also ignore this page and move on to the old widgets.php and everything will be back to normal. The second way to do this would be to stick to the default interface and group widgets, which previously were assigned to the same sidebar, together in the inactive widgets area and still notify the user to reassign them this way.

The second part, enhancing auto assigning  would require a mentor who is native with how WordPress handles widgets. I would need some support understanding the different widgets.php’s in core. The idea here is to auto reassign the widgets in the new interface and highlight them in some way so the user can just check if everything migrated to his appeal. This could be partly accomplished by matching the old sidebar ids and (english) names to the new. Many themes already use sidebar-1 sidebar-2 etc. Fuzzy string matching could be accomplished using the Levenshtein distance – PHP has a integrated function for this.

My initial idea of Widget Collections could still be used in a plugin and so in combination with the core changes described above would make everyone happy while only adding complexity for those who need the added functionality. This would be something I could work on after GSoC. The here proposed project also should start off as a plugin – at least until midterm. Depending on feedback I could work on core integration afterwards or refine the plugin for releasing it to github and the WordPress.org plugin repository.

Update: While this project did not make it into GSoC there is now work going on to enhance the WordPress widget experience: Read more.

Code Revisions

WordPress end-users mainly are interested in doing quick changes to integrate a plugin into their theme (main support question for my featured video plugin) or implement a bug fix they read about in the support forums for a not so well updated plugin. They should not need to know how to use FTP or external editors. Developers won’t, no matter how highly the WordPress integrated code editors are extended, rely on those for their daily development routine. Therefore I do not think it is necessary to blow up the code editor with features like GIT/SVN functionality or other fancy stuff full featured editors ship with. The WordPress editors should be quickly accessible for small changes and act as launch pad for to-be developers.

There are already awesome plugins out there to enhance the functionality of the code editors. Code highlighting, line numbers etc. But something, which is part of WordPress core since version 2.6 (according to wp-includes/revision.php), is not available for the code editors yet. Code revisions would be of high interest when something breaks after editing a file. This is one reason many users do not try editing code directly. When being able to smoothly go back to an older revision this concern would be arbitrary. Post revisions got much attention in the WordPress 3.6 release cycle. I think it is time to bring them to the code editors.

Everything I propose here should be able to start off as a plugin. But I also think my approach to this would smoothly fit into core and would not add much new complexity because I want to stick to already available workflows.

My approach is to stick to the new revision viewer with a custom post type. When a file is modified the first time the plugin will add a new post to the database containing the current (new) state of the file. Furthermore a revision from before the file save is created. WordPress already ships with plenty of functions which should be also usable for a code revision system, as soon as we associate a file with a post in the database. A problem here is to associate a post in the database with a specific file on the server. This requires the creation of a UID from filename + theme/plugin slug + author for connecting posts with their corresponding files.

The new revision viewer uses backbone.js – while I am not native coding backbone I feel comfortable reading it. From what I got until now the new revision viewer code seems very flexible and should be nicely portable to a new code revision page.

A mentor native with the new revision management and backbone would be awesome. Other than that, I do not have any preferences here. I think nacin initially suggested the idea..?

Update: I got accepted to GSoC with this project! Follow the progress on make/core!

Widget Collections

 
34 Kudos
Don't
move!
This is my main proposal for the Google Summer of Code. Depending on the feedback I would also like and consider working on the Template Versioning project. However I think that this here proposed Widget Collections project is of higher interest for a bigger part of the WordPress community.

I already sent an email to the wp-hackers mailing list, but there were plenty of GSOC requests (I think I was like the 3rd of 15+) and not many got feedback other than that they should attend in a certain IRC meeting. So I thought – because this would have been the next step anyway – I would just write my proposal down in a blog post.

The initial input for the following comes from WordPress Ideas and Jesse Friedman’s blog post about the topic. While the idea will give you an overview of the problem which this project targets to solve, I here will start off describing it shortly.

Problem

With WordPress evolving from a blogging tool to a full featured content management system widgets got more important than ever before. They no longer hold just lists of categories or a blogroll. With 3.5 the blogroll and with it the links even got disabled by default. Widgets now often hold an important part of the website. But still – the widget functionality did not get a rework like other sections of the CMS in the recent releases. When changing themes often the whole widget layout is messed up and needs to be redone. Hopefully the site administrator remembers the widget setup from before to redo it one by one. Managing widgets can be quite a pain when they are a big part of your website.

Concept

This is where Widget Collections shall hook into the process.Widget Collections Mockup Widgets no longer stand on their own, but are part of collections.  Widget Collections do not change anything in the way themes display widgets – they are only displayed as containers around certain widgets in the backend. They are a combination of sidebars and widgets: They hold widgets like sidebars do. Drag and drop widgets into their borders and they will enhance around them. They also can be named for better differentiability. But still – they are them self drag and drop able and snap into sidebars. When assigned to a sidebar Widget Collections do not occupy it for their own – a sidebar can hold multiple Widget Collections and collection-free widgets. For the user this changes nothing at first. He as always assigns widgets to his sidebars. When hovering a sidebar with widgets assigned to a light grey border is shown which suggests the manual creation of a collection. When the theme is changed the contents of a sidebar (if before collection-free) are auto grouped in their own Widget Collection so that the user can quickly reassign them to the new sidebars in their old combinations. Also stackable Widget Collections (e.g. 2 layers: One widget collection holds multiple small ones) might be worth considering. 

Implementation

As discussed on the wp-hackers mailing list not many GSOC projects make their way into core. For a fully accessible enhancement of widgets.php through widget collections this would need core changes I guess. But the part which will be used by most users (JS/jQuery based) is also possible to implement using a plugin. The plugin would basically dequeue wp-admin/js/widget.js (handle: ‚admin-widgets‘) and enqueue a version of it which includes the new functionality. The second layer would be to represent the current state if the collections in WordPress options. So widgets.php won’t be edited and load all widgets as normal. When finished loading the Widgets Collections JavaScript would come in wrap the widgets in their corresponding groups etc.

There would be two different layers of collections. The first one is visible to the user and was before created by the user or by a recent theme change. The second is invisible to the user and just remembers which widgets are assigned to which sidebar. Further the plugin keeps track of which theme is active at the moment. On every load of widgets.php the plugin checks whether the theme has changed. When this is the case the invisible collections are upgraded to visible ones and named after the sidebar they were assigned to before.

Due to not being able to replace widgets.php from an plugin this implementation won’t be usable without javascript enabled. This then would need core changes I also would be keen to work on if requested.

Extension

A further extension would be visibility options for assigned widgets. This would have a similar use case to the inactive widgets area but won’t require widgets to be removed from their collections and sidebars. This could be nicely implemented using a small eye icon next to the widget title and expand arrow as seen in Adobe Photoshop for layer visibility: photoshop-visibility-eye.

Another possible addition which would come in handy in combination with widget collections would be a supercharged text widget. The text widgets hold all kind of content today, so it would be a nice move to make them full featured. I do not think this would make it’s way into core. It would need plenty of testing because of all the different use cases of the current text widget in order to replace it. So I would again propose this as a plugin or to directly ship with Widget Collections. My idea for this one would be for the supercharged text widgets to rely on a custom post type, but not the full post.php editor. A small button in the textarea would bring up a thickbox powered editor with basic tinyMCE, media and revision capabilities.

I hereby hope to get some feedback, especially from potential mentors. I did not contribute to core yet so I can not name anybody I would like to work with particularly. It would be good to have a mentor who took part in the creation of the Widgets API – especially if this project might be interesting for core integration. Elsewise this project will require much jQuery coding – so someone with experience there would be awesome! I guess my three plugins in the WordPress.org Repository are the best reference for this proposal.