ProcessWire Recipes

As you may have noticed, the rare articles on this blog here tend to have an emphasis on a system called ProcessWire.

I'll try not to overly evangelize here - but at least for me PW is a Content Management System (or Framework) that is often times a smart, extendable, maintainable and in the end reasonable choice as website-engine. Unfortunately because of its sheer popularity, many colleagues chose WordPress in some kind of knee-jerk reaction - whether it's suitable for that particular project, or not. "Nah, it has plugins to solve that" But that's actually a kind of other story.

Current web development industry lacks many things - but too few Content Management Systems isn't one of them. It's hard to stand out from the 23%. Not intending to position ProcessWire as direct competitor to WP, but feeling the urge to help realize and work against said WordPress reflex I wondered how to do so (and since I'm having no favorite soccer club to cheer to, there's plenty of rooting energy left ;-).

So, together with the superb help of Christian, there's a little website available for more than a month now - Process Wire Recipes. What is PWR exactly? In my opinion a little building block that lacked in the ProcessWire universe until now: a directory aiming to collect mini-tutorials for common and not-so-common tasks and problems, presented in concise and spot-on format.

In the midst of a project I looked for a mini-tutorial of how to implement one special feature (using CKEditor in the front end - ironically, I still have to write this recipe), ideally short and concise, not starting from the beginning of (PW) creation, and not introducing things that I already know (essential parts of API). Jealously I looked over to the Laravel universe, and especially laravel-recipes.com.

Therefore, I started a thread in the forum, asking whether a comparable project already existed in the ProcessWire world and I'm not aware, or if such a site would have potential, if demand would be there. In that topic I tried to outline the target group - developers, not essentially beginners (with ProcessWire) but in general relatively seasoned PW devs who just need a boost in the right direction with a hint to the right approach or, for example, API call.

PWR Screenshot

"ProcessWire Recipes" should be structured with a index and most importantly, tagging, thereby bypassing the not-so-ideal ProcessWire forum search. Intention was not to create a parallel structure to, but complement to the already established knowledge hubs - official documentation and Forums. But with leaving the discussion part away, and giving it a situation-based (problem-solution) approach, instead of the more architectural one of the docs.

But as already mentioned in the forum post - the crucial thing is recipes and therefore contribution from the community. This consists of two things imho, Awareness and Process. Fortunately, awareness for the project is there - PWR is mentioned frequently in Teppo's ProcessWire Weekly and even in the footer of the processwire.com!

But the process, the way of contributing was also hard to tackle. Since aiming at developers, contribution via Pull Requests would be ideal - but (in this case) unfortunately, ProcessWire is database driven. A system like Kirby would have been perfect - but how would that look, to build a ProcessWire recipe site on a non-ProcessWire CMS? ;-)

Luckily, the awesome conference Beyond Tellerrand arrived in Berlin at the right time. And that effect of wanting to build things afterwards as well. While hanging out with Christian he had the idea an importer of markdown files into "real" ProcessWire pages. He was eager to join this little project, to build the feature, and did instantaneously. In the meantime we messaged with (and met) Nico Knoll, agreeing on that design will come from him eventually.

Beyond Tellerrand was kindling things again. Unfortunately (hobby-wise), but fortunately (business-wise) that last two months of 2014 were full of client work and delayed the project a bit. But in the beginning of December, the little reicpe site finally launched - processwire-recipes.com - with an interim design, and also very few recipes, but, I hope, also with a lot of potential.

So, once again, many thanks to my accomplice Christian, all the contributors so far and not to forget all the positive feedback during PWRs inception. All in all, it was neither the re-invention of the wheel nor a totally new idea - but maybe us, the ProcessWire community, can help to make the site sustainable by eagerly sharing their tiny bits of ProcessWire wisdom - in order to promote ProcessWire and all of its advantages. And maybe to help convince some fellow developers to build a particular site in a real powerful Content Management Framework.

Named mediaquery indicator

To start the new year with a snippet (and to end the overly long blog hiatus) I'd like to share a little SCSS debug helper.

If you, like me, follow the route of naming your media queries (in the sense Chris Coyier describes here), and put them into modular SCSS partials, it can be sometimes quite useful to tell at a glance which mediaquery is currently active in a particular browser view. Sure, you could fire up the browsers inspector and look it up, see concrete values and then remember the name of your responsible partial, but alternatively you can implement this:

/* For example in your project wide settings partial */

@mixin mqindicator($mqname) {
    @if $debug == true {
        body:before {
            position: fixed;
            top: 0;
            right: 0;
            left: auto;
            bottom: auto;
            z-index: 100000 ;
            display: inline-block;
            padding: 5px 10px;
            background: red;
            color: #fff;
            content: ''; // resetting
            content: $mqname;
        }
    }
}

/* Actual breakpoints, preferably in their own partials.
     Find an example for the mixin breakpoint() and config
     here: http://codepen.io/marcus/pen/azmage */

@include breakpoint('beta') {

  @include mqindicator('beta');

  // Other rules...
}

@include breakpoint('alpha') {

  @include mqindicator('alpha');

  // Other rules...

}

This shows a small, fixed indicator, outputting anything you like - although the mediaquery's name makes really sense ;-)

For this to work and in order to not needing to comment this out before deployment, you have to set the variable $debug to true:

$debug: true !global;

If not yet used in your projects, such a variable makes sense serving as a switch for debugging like this. Please note that the !global variable setting requires Ruby Sass and is not yet supported in node-sass.

WordPress and the perception of the work of developers

This weekend I stumbled upon a blog post from wptavern.com, a site dedicated to WordPress ecosystem and community. Up until a portrait of ProcessWire in one of their articles I haven't even heard of the WPtavern, but I'm sure it is a well visited site with certain influence in the community.

Aforementioned article quotes web developer Mario Peshev, both specialized in WordPress and frameworks such as CakePHP. He notices both in his accounting books and work experiences that the money is not being made by WordPress related jobs, but by the other framework services he offers. The article's author states:

It seems curious that Peshev would regularly receive more offers for CakePHP work, originating from older code he’d written, versus requests for WordPress, which powers more than 23% of the web.

No, it is not. The spread of a tool does not automatically equal big potential does not automatically equal good income for seasoned developers of this tool. Whilst CakePHP is an application framework, WordPress is an article- and media-management tool. That offer gap is totally explainable.

But besides from the faulty comparison between WordPress and pure bred PHP frameworks WPtavern's article deals with the public perception of WordPress and development work as a whole. And that got me thinking: Can dissemination and undoubtetly ease of use and setup act on customers who just aren't aware of the value of (custom) development work?

According to the article, that already happend. Users buy a premium plugin for $ 25 and expect custom modification work on it to be in range of $ 15. And when reflecting on my own rare WordPress jobs in the past, its observation is totally valid. Often times, clients supplied a purchased theme and estimated the modifications of it relative to the theme's price (German speaking readers: Here's blog post from Gerrit van Aaken dealing with this phenomenon, among other topics).

In short, WordPress ease of use and sheer amount of plugins backfires:

He [Peshev] outlined a typical scenario that plagues many development agencies. Because users can piece most of their sites together without help, they figure the rest should be easy.

This effect is true to both the WordPress community and to the web developer community at large. Although Google became "the internet" for some people, WordPress must not become "the web app" and installing plugins and themes "web development" in people's perception.

Don't get me wrong, I have nothing against ease of use for end users. Not at all, this should always be the goal, and that is also ProcessWire's aim. But devalueing the worth of the engineering and architectural parts of web developers work will harm said developers - and eventually the systems they create. This is especially true for the motivation-driven world of open source software.

An ecosystem full of (sometimes matching) plugins and themes, and a community that creates said ecosystem has a responsabilty towards the industry - especially when it becomes mainstream and a house hold name for the branch of editable websites. To misquote Spider-Man, As for Wordpress, 23% market share and big marketing powers come with great responsabilites. Although this article appeared on a site dedicated to WordPress I'm not sure that Automattic and the WordPress community is aware of this.