ProcessWire weekly #9

In this ninth issue of ProcessWire weekly we'll be covering our regular topics, such as core and module updates, recent forum updates and more. Read on!

New stuff in core (dev branch), new modules, new and interesting forum discussions, and at least one article that has sparked quite a bit of discussion (and some controversy) by pitting ProcessWire against WordPress.

Yet another interesting week for ProcessWire as a project and the ProcessWire community alike. Keep on reading to see what's hot right now!

Brief summary of latest updates in ProcessWire's dev branch

Updates this week include optimisations for Selectors, addition of new sort field setting to PageTable, improvements and new settings for Inputfield Selector (all config settings are now included at the top of InputfieldSelector.module, by the way) and an upgrade to make modules load order more consistent.

Load order update means that module dependencies now affect the order in which methods like include() and __construct() get called, not just init(). This should make it easier to have a module that extends another module (in OOP sense) using PHP's "extends" keyword.

Note: for the load order update to have an effect on your modules you'll have to convert them to use the new ModuleName.info.json or ModuleName.info.php methods instead of a getModuleInfo() method.

Accordion textformatter by Tom Reno turns regular text into an accordion

Accordion textformatter by Tom Reno turns long content separated with five or more hyphens (and titles, e.g. "----- Accordion item title") into collapsible accordion items.

Very similar to pagination textformatter published by Ryan just a while ago, this is another way for making long content more usable – or simply adding an accordion, if that's what you're after.

Apparently the idea to publish accordion to the modules directory was sparked by Ryan's pagination textformatter – as Tom explains here, the module has been in use for almost a year, but was just now converted to use similar markup pattern as the pagination module.

Moral of the story: if you've got a module you just haven't put out yet, getting it out there could spark someone else to publish something similar, thus benefitting you both!

Trumbowyg inputfield integrates Trumbowyg editor into ProcessWire

Trumbowyg inputfield by yours truly integrates Trumbowyg WYSIWYG editor into ProcessWire. Trumbowyg is a light-weight alternative to more feature-rich editors, such as CKEditor and TinyMCE.

Another module with a background story worth mentioning: after seeing this post on the forum, I decided to give it a try and an hour later there was a Trumbowyg inputfield module available for ProcessWire.

The moral of this story is that, first of all, building modules for ProcessWire is surprisingly easy, and second of all, if there's something you'd like to see implemented in ProcessWire, say it out loud – someone just might do it.

Potential users should note that Trumbowyg is still in alpha state, so this is for testing purposes!

A few recent forum topics to check out

Just a few picks from the forum this week you might want to check out:

  • In the continuous integration thread there's been some pretty intense discussion about methods of storing data and metadata this week -- file system vs database, etc. Ryan's replies alone are worth checking out, as they may give us a hint about things to come.
  • As a less serious topic, how'd you like some ProcessWire wallpapers? Big thanks to forum member blad for starting the discussion and Soma for his contributions!
  • A subject that surely affect the sites of us all: ProcessWire and SEO. Got any good resources or tips of your own to share?
  • And finally, what's news for A List Apart and Craft is already old news for ProcessWire.

The post that has sparked quite a bit of discussion: ProcessWire vs WordPress

Mike Johnston of CMS Critic published a post about why he (and the CMS Critic staff) prefer ProcessWire over another platform we all know and many of us have quite strong feelings about –WordPress.

For anyone who hasn't heard about this before, CMS Critic moved from WordPress to ProcessWire just over a year ago with some help from the father of ProcessWire, Ryan Cramer himself. Seems to me that they've been quite happy with this move too.

This particular post, somewhat argumentatively titled ProcessWire vs WordPress, has (not too surprisingly) sparked quite a bit of discussion already. While the post itself is well worth checking out, the comments are what really give it extra value. Recommended reading!

Hope you didn't miss our previous issue, but just in case you did ...

I honestly don't like repeating myself, but just in case that you missed our previous issue, there was one thing that you most definitely shouldn't miss: Dynamic Roles module built by Ryan, invented by Antti Peisa and sponsored by Avoine.

By adding so-called dynamic roles on top of our regular old-school roles system this module makes it possible for you to define permissions literally on the fly, based on whatever factors you consider important.

Should all users with an email ending with gmail.com gain edit access on blog posts tagged "gmail" and view access to your special extranet area for Gmail users? Easy peasy!

(Seriously, if you haven't yet checked this module out, do it now.)

Site of the week belongs to a hairdresser in Slovakia – Miluj Svoje Vlasy

Miluj Svoje Vlasy is a Slovak hairdresser with a brand new and totally gorgeous site powered by ProcessWire.

Built by Darren Newberry (DAZZYWEB) this site is responsive, full of cool little details and based on a design that makes it easy to find your way through the site and check out important details (such as opening hours or the integrated booking system).

The site uses a responsive grid system called Cute Grids, built by Darren himself. As far as CSS grids go, this one looks pretty neat and compact. Definitely worth checking out too!

Stay tuned for our next issue

After all the big updates from last time, I was afraid that this issue would turn out empty. With all the stuff happening in the forum, Twitter, GitHub etc. that's hardly a problem anymore – in fact each week there seems to be more and more stuff to post!

.. and with audience like this, who wouldn't love to write these posts?

Anyway, that's it for this weeks ProcessWire weekly, more news next time. Our next issue will be out Saturday, 19th of July. Until then, happy hacking with ProcessWire!

This post has 2 comments:

Ryan Cramer on Saturday 12th of July 2014 15:16 pm

Great edition Teppo! I want to expand on the module load order mentioned above. You don't have to use a module.info.json or module.info.php file in order to benefit from load order. You only need that if your module happens to extend another module (in the PHP OO sense). This just enables PW to find out about your module and its dependencies BEFORE it attempts to include() it.

Consider this scenario: you've got a module called TextformatterGreat that extends TextformatterGood. If you try to install TextformatterGreat before you've even got TextformatterGood on your system, then PW would include the TextformatterGreat.module (in order to call its getModuleInfo method) and experience a fatal PHP error (since the class it extends doesn't exist and can't be found anywhere). By moving the module information to a separate TextformatterGreat.info.jon or TextformatterGreat.info.php file, that problem can be avoided entirely, so long as TextformatterGreat has: 'requires' => 'TextformatterGood', in it's module information.

The load order update is a bit of a different thing, though it is also affected by the 'requires' in your module info. Previously if your 'requires' indicated that it required another module, and both were autoload modules, then PW would ensure that the init() method of the required module was called before the init() method of the module requiring it. In the latest update, PW goes a bit further and now ensures that both the include() order and __construct() order of the modules are also affected by the dependencies in the same way. This doesn't matter much in terms of one extending another (when both are installed) since the PHP autoloader would already take care of that. But it can matter if your module is doing anything related to the other module in the __construct(), as some do (like LanguageSupport modules). The gist is that the 'requires' option is now a lot smarter/more useful.

Mike Johnston on Sunday 13th of July 2014 20:37 pm

Thanks for the mention and great roundup. I hope our post helped spur some additional interest in what we feel is an excellent product.

Mike from CMS Critic

Post a comment