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.
