Doug Bell (aka preaction on IRC and various other places) wrote a series of articles about WebGUI 8. You’ll find them in his blog and archives at blogs.perl.org.
If you are a regular user of WebGUI 8, then you should spend some time in the new Admin Console to get a feel for how it works. It’s always a good idea to learn how to use Template::Toolkit as it will save you time and give you more power and flexibility in your templating.
If you are a developer of WebGUI and want to work in 8, then I suggest the following list of modules:
After WebGUI 8 is released, our focus will be stabilize it. We will also resume making 7.10 releases as time and resources allow so that bug fixes get out to our customers and users.
The release of WebGUI 8 will obsolete some RFEs and bugs, and they will be closed. It will also give us the chance to fix some long standing problems with WebGUI that could not be easily fixed in 7.
Hopefully, the last post whet your appetite for using WebGUI 8. You should remember that when WebGUI 8.0 is released, it will be a beta. Beta means that www.webgui.org and www.plainblack.com are using the software, and that we expect it to be usable but less stable than 7.10. This helps to guarantee that we feel your pain, even before you do.
The new Admin console required changes to the Layout templates. Existing templates will continue to work, with caveats I’ve described in this blog post. As part of an early effort to make WebGUI 8 more compatible with Template::Toolkit, variables were changed in two macro templates. Existing templates will be upgraded for the new names.
It has taken many man-weeks of time to upgrade our custom code. If you have custom code, you should have similar expectations. Large pieces of the WebGUI API have changed. To help developers understand the extent of the changes, we’ve created a migration document that you can read now on github.
People familiar with WebGUI know to read the gotchas file for more details about what is changing.
WebGUI 8 will contain new bugs. Some of them are already on the bug tracker. More discussion about bugs and 7 vs 8 in the next post.
It’s been a long time since WebGUI 8 was initially announced, and from the postings on forums and questions on IRC I have the feeling that:
That changes today. This is the first in a series of posts to answer FAQ-type questions about WebGUI 8. If you have a question like this, please post them as a comment to this blog.
So, what are the benefits of WebGUI 8?
Simply, WebGUI 8 is supposed to be a faster version of WebGUI 7 in two aspects, from a UI perspective, and from a development perspective.
From a UI perspective, we’ve made WebGUI use less memory and be faster at generating content. The new Admin Console is an AJAX application, so managing Assets does not require loading a new page for every edit.
From a developer’s standpoint, we’ve made it easier to write WebGUI code. WebGUI 8 is much more modern. We’ve adopted Moose for most objects in the system. We use Plack. WebGUI 8 will take advantage of perl 5.10 features like smart match. All of those changes, and others unmentioned, mean API changes.
But that’s the next Post, “What are the risks of upgrading to WebGUI 8”.
The coding for the custom apps is done. The HelpDesk, Karma Gifter, and Bazaar are all working in WebGUI 8. However, there is still one more hurdle to overcome, and that’s the WRE.
The WRE for WebGUI 8 will be very different. Instead of apache and modperl, we will be using starman, which is a small webserver written in Perl and C. Instead of apache’s modproxy, we will be using nginx, which is a high performance proxy server. The backup system has been changed to use rsync instead of sftp for more speed in backing up sites with large uploads directories, and instead of a custom log rotation system we will be using logrotate.
What does all this mean?
However, just like WebGUI 7, it is possible for developers and advanced users to run WebGUI 8 in an environment without the WRE. Instructions will be posted in the next few days on how to do that.
My hope is that several of you from the community will do that, and help with the testing of WebGUI 8 beta. I have been posting version 8 specific bugs to the WebGUI bug tracker, with 8: as a prefix in the bug title.
There are three main custom apps used on plainblack.com and webgui.org:
There are some custom macros, but macros only change if they use the Asset, Session or Auth APIs.
As of this evening, both the Karma Gifter and the Bazaar are working in WebGUI 8. They could use some CSS and layout work, but they’re functional.
That leaves the HelpDesk, which is really the most important user facing app that we use.
Yesterday we finished the conversion of most of WebGUI’s tables from MyISAM to InnoDB. The only table that stays is the table used for doing searches in WebGUI. Someday we’ll replace out text search with a real plugin like ElasticSearch or something similar.
That means that the development part of WebGUI 8 is done. Now, we have to make sure that Plain Black’s custom code (the HelpDesk and Bazaar) still works, try converting some large sites and fix bugs and then we can release it.
If you’re interested in the bug fixing part, please make a post on the dev board.
If you have a site with its WebGUI configuration files all set up, and then you decide that you want to reset the site contents back to a default state, the wgd utility can help you with that.
You would download it, make it executable, and then run this command:
wgd -F my.site.conf reset —backup —import —starter —uploads
You should read the wgd help documents for more details, however, here’s a brief explanation of the switches
-F : pick a particular site by it’s WebGUI config file
—backup : make a database backup for safety
—import : Import a new database dump, by default, use the one from WebGUI for a new site.
—starter : Turn on the site starter
—uploads : Also reset the uploads directory with default contents
The old style layout template work with the new Admin Console, with a few caveats:
The good news is that they keep the arrangement of your content, they allow drag and drop rearranging, they still allow editing of content, and to users who cannot edit your site, they’ll look the same. That means that we’ll publish information on how to upgrade the templates, and then continue on.
There is one last hurdle to check before we can begin testing upgrades on WebGUI 8, and that the conversion of the database tables to InnoDB. This will be a performance improvement for WebGUI 8, but if it fails would not actually prevent us from releasing it soon, we could work on the conversion and make it part of 8.1, or even an early release in the 8.0 series before it’s declared stable.
I’ll have another posting before Thanksgiving with the results of the conversion testing.