Sarah and Jeffro over at wptavern.com are talking about WordPress 3.7 and my recently completed Code Revisions Google Summer of Code project. For the Code Revisions part start listening at around 11 minutes in. Jeffro is struggling quite a bit pronouncing my last name.. Well, german umlauts!
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/
My featured video plugin is getting some good feedback on WordPress.org. I just released version 1.8 which overhauls the local video feature using the freshly available Video.js 4.0. Take a look into your media settings and customize it!
With version 4.0 the licence of Video.js changes from LGPLv3 to the Apache Licence v2 which is compatible with GPL and therefore.. nothing changes for my plugin. Nice
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
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.
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.
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!