I just published a long awaited update to my WordPress Featured Videos plugin – get it on WordPress.org.
The plugin has over 10 000 active installs (thanks dotorg team for finally showing numbers like that!) and nearly 60 000 downloads with an average of ~70 daily. The ratings are close to perfect: 46 in total, all 4 stars or more. 41 of them give the highest possible rating of 5 stars. A smooth workflow and sticking to the native WordPress UI experience seems to be paying of. The bugs mentioned in the 4 star ratings should be fixed in this version, lets see if some change their rating. Only thing not fixable: The plugin still does not work with all themes out of the box. No workaround here. I even have been in contact with the Genesis Framework guys in order to try to enable automatic integration with their themes – sadly I haven’t been able to resolve it. Update:Check out issue #5 on the plugin’s GitHub repository for details.
This release brings a massive code refactor and introduces support for all media providers also supported by the WordPress core. There is a detailed list in the WordPress Codex, to name a few:
As before: Local Media, YouTube, Vimeo, DailyMotion
SoundCloud & Mixcloud
Spotify (plays inline if users are logged into the Spotify web player)
2.0.0 also drops support for all WordPress versions lower than 3.7. With future releases I will support versions of WordPress which are also still on the official list to probably get security updates:
Previous major releases from 3.7 onwards may or may not get security updates as serious exploits are discovered.
Due to some hassle with svn (I normally prefer git for version control) there was a quick 2.0.1 follow up. Additionally I just pushed 2.0.2 because I ran into some variable undefined warnings while previewing this very post.
Version 1.9 replaces the Video.js local video player with the WordPress native MediaElement.js player. While this means less clutter for the plugin and a more native feel it also breaks local video support for installations running WordPress 3.5 or older. On the other hand: No need to update the plugin if you do not upgrade your WordPress installation anymore!
Second big update is the Spanish localization! Maria from WebHostingHub.com contacted me around two month ago and was happy to translate the plugin. Thanks!
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.
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.