Introducing IftRunner and the story behind it

This week is a different week here on the ProcessWire blog. Ryan is on holidays and he asked me to write this blog post. It's a great honor and I wanted to use this as an opportunity to tell you a little bit of our company's background with ProcessWire. There is also a surprise module release for you all.

Before we start, let me quickly introduce myself. My name is Antti Peisa, also known as apeisa at the forums and twitter. I work as a production manager at Avoine, which is a web company from Finland.

• Collaboration between Avoine and ProcessWire
• Building complex web application with ProcessWire
• IftRunner release

Collaboration between Avoine and ProcessWire

If you follow ProcessWire development (as most of you who read this blog do), you might remember seeing Avoine mentioned every now and then. We started using ProcessWire to build websites for our customers around 2012 and back then one of the first obstacles was the lack of multi-language support. Most of the Finns do understand English, but many still prefer to use the software in our own language. So the lack of multi-language support was definitely a big issue for us. After a few emails with Ryan, I felt very confident in future of ProcessWire. It was also clear that multi-language support was coming, but we needed it as fast as possible. We decided to boost the development with a sponsorship deal. That turned out great: soon we had the ability to translate the PW admin interface, but also a good foundation to manage content in multiple languages. Every year all aspects of ProcessWire have improved and so has multi-language support. Today ProcessWire has the strongest multi-language support I know (at least on the php cms/f space).

Multi-language support was just the beginning of a collaboration between Avoine and Ryan. After that we needed inputfield dependencies in one of our projects. This was second project where Avoine gave some money and ideas so that Ryan could build fantastic features. I think inputfield dependencies are a brilliant feature that is rarely seen and in ProcessWire it is done very well. Today the ProcessWire admin itself uses inputfield dependencies here and there and they really boost the usability.

Last year Avoine started a huge software development project to create our next generation member management platform (pretty close to CRM software) called Avoine Sense. Earlier collaboration with Ryan was a great foundation and gave us confidence boost to start building Sense on top of ProcessWire. During product development, we ended up sponsoring quite a many features that ended up either in PW-core or as separate modules. Here is a list of features that we have sponsored and have all ended as part of ProcessWire core:

• PageTable
• Notification system
• Selector fieldtype and inputfield
• Selector string to support API-variables (user, session, page)
• Advanced selectors: subselectors and or-groups
• Possibility to allow other templates than user to login

Building complex web application with ProcessWire

Sense is quite a large application, if we compare it to projects that are usually built on top of ProcessWire. We are not ready yet (first client projects will start in month or two), but here are the current stats:

• 1750 commits from 8 developers (currently 4 working on)
• 1½ years in development

We decided to build Sense on top of ProcessWire for two main reasons:

• most of our new software had already been built using ProcessWire (and all our developers loved it)
• featurewise PW included much more we could use compared to more traditional frameworks (like Zend, Laravel or Yii)

Of course many features of ProcessWire are website specific and were not required (like page urls for example) and some features worked in way that didn't help us at all (like user access). That was a small price compared to what we got out of the box. I am not saying that there hasn't been any moments when we would have wished PW to behave more like traditional web application framework and less like a content management framework - but I think much less than we originally feared. In our application we use PW admin as a backend for our staff (customer service, project managers, programmers - all use PW admin to manage our client's application), while our customers have 100% unique admin UI for their usage. For the UI we hired Ville Saarivaara (aka Fokke from forums) to help us build something totally unique in boring sea of registry applications:

What might be interesting for most of you considering ProcessWire for bigger projects or as a platform for SaaS application are the technical decisions we made with Avoine Sense:

• it is 100% cloud based and load balanced, running on top of AWS (Elastic Beanstalk, S3, SQS, ELB)
• all persistent data is stored in S3
• sessions and other cached data are stored in ElastiCache
• ProcessWire databases are running as RDS-instances
• API and workers (which process time consuming tasks) are running as separate applications
• we built REST-API with OAuth2 authentication that allows read/write access into our PW instances
• all instances are handled through the same PW application, instance specific configuration is loaded from DynamoDB in realtime

We are living very exciting times at Avoine since we can finally start showing our customers what we have been building. It is also rewarding to start sharing many of the technical aspects of our project with the ProcessWire community. Please do ask us here in the comments if you are interested hearing more about these themes.

IftRunner release

During Sense development Ryan built us two big modules that we have open sourced together. First one was Dynamic Roles, which we released over year ago. Dynamic Roles allows a very flexible way to define user groups and their view/edit access (both based on selectors). While we finally ended up not using Dynamic Roles in our project, I feel it is great module and definitely something you should consider if PW's default access management doesn't suit your needs.

The second module is the surprise I mentioned in the first paragraph. This beauty has a bizarre name, called IftRunner, which could be translated: "If this happens, then do that". It is basically a visual GUI for defining hooks and launching actions based on those hooks.

What this really means is that you can define triggers like:

• "each time page with news-item template is created"

then do these actions:

• "send this email to allcompany@example.com"
• "tell my newsletter application that it can send update to list x"

The most common use case for us is quite simple: we use IftRunner to update title fields based on other fields. For example, when pages with "member"-template are saved, we make sure that title stays as "<firstname> <lastname>". What is really cool in our case is that some of our customers want more information into their titles than others. Usually this would require a custom changes in code or client specific module - now we can just make the changes through the IftRunner's admin interface.

IftRunner is not a tool that all websites need. In fact very rare websites actually do make a good use of it (this is the reason it is separate module and not a core feature). But if you are building something more complex (like some sort of web application) or you are afraid of module development (don't be, it's easy!), then IftRunner might be an enormous help to you. The real power comes from the fact that you can build more actions yourself that IftRunner is able to launch.

There isn't readme or proper instructions yet, but most adventurous of you might enjoy diving into IftRunner (you can find it on GitHub). Together with Lister Pro, you can achieve quite a complex logic and processes just by using ProcessWire admin, without any coding. The problem is that there are quite few actions currently, so if you don't build the ones you need, there isn't too many options yet. Here are few screenshots though to get sneak peak without installing it.

Thanks for reading! Please ask any guestions you might have below, I will follow comments section actively for the next week.

-Antti

Comments

• 

  Mats

  • 6 years ago
  • 41

  Thanks for sharing, Antti! Very interesting story and very impressive use of PW.

  Reply

  • 

    Antti

    • 6 years ago
    • 21

    Thanks for reading it Mats!

    Reply

• 

  Antti

  • 6 years ago
  • 21

  Thanks Tom!

  Reply

• 

  adrian

  • 6 years ago
  • 31

  Great read Antti - thanks for all the ideas and support that you and Avoine have brought to PW!

  Reply

  • 

    Antti

    • 6 years ago
    • 21

    Thanks Adrian. Happy to be part of this community!

    Reply

• 

  Teppo

  • 6 years ago
  • 31

  Great post Antti, and happy to hear that things are looking good for you guys.. and Sense, of course! :)

  I for one wouldn't mind hearing a little bit more about how you made the cloud part happen: what particular difficulties did you face and how did you get over those, any measures you took to get the most out of that environment, and perhaps just some general do's and don'ts – stuff like that.

  Reply

  • 

    Antti

    • 6 years ago
    • 51

    I have to ask Sebastian (our software architect in Sense project) to answer this one in more detail (actually, it would probably require own blog post or two), but in my opinion pw works very well at AWS. Most complex thing was persistent files. We ended up building FieldtypeS3File, which is something we probably want to open source at some point.

    Before we settled using Elastic Beanstalk, we had tried (meaning we had easy way to deploy pw/sense instances on them) Deis.io (running at AWS) and Cloudformation. Finally the simplest solution was the best for us.

    BTW: In this current setup Avoine doesn't have to manage any servers. Elastic Beanstalk handles deploying new code to the servers and management of the necessary server resources. Part of this same theme was decision to move code hosting to GitHub.

    Reply

• 

  BernhardB

  • 6 years ago
  • 31

  hi antti, great writeup! :)
  could you give us a short example of what you mean by "iftrunner and listerpro together quite complex achievements..."?
  all the best for you/avoine/sense and like adrian said: thanks for your great contributions!
  cheers

  Reply

  • 

    Antti

    • 6 years ago
    • 41

    Thanks Bernhard! Things where you run actions to pages from Lister Pro, then there are triggers that activate on certain change and do further actions.

    For example, you mass edit field values from lister pro and mark 100 pages to as "revieved" (checkbox field). Then you have trigger on Page Save, that looks that each time page which is saved and will have its reviewed box checked (and maybe some other values?) then does something more (like send email, move page etc...).

    Reply

• 

  Tom Reno

  • 6 years ago
  • 11

  *Releasing (dang autocorrect)

  Reply
• 

  Adrian Mak

  • 6 years ago
  • 21

  The IftRunner module, in Drupal world, that's the Rule module

  Reply

  • 

    Antti

    • 6 years ago
    • 21

    Yep, they seem to be pretty close!

    Reply

• 

  Eduardo

  • 6 years ago
  • 51

  A really nice read! The beautiful multilanguage implementation was one of the things that made me fall in love with PW it's really interesting to know how it came to be.

  I'm a newbie programmer but with PW I feel no fear messing around with the code either in modules or reaching for data through the API, thanks for the extra courage anyway! :D

  Reply

• 

  Tom Reno

  • 6 years ago
  • 62

  Antti,

  Excellent write up. I'm really looking forward to working with IftRunner. Big thanks to You/Avoine/Ryan for building and realizing this.

  Reply
• 

  mr-fan

  • 6 years ago
  • 00

  Ups tags are getting stripped...so my first phrase should be more like:

  IF THIS module goes opensource THEN say Thank You Antti&Avonie...

  Reply

• 

  SiNNuT

  • 6 years ago
  • 31

  Nice write-up! Very interesting. I'm curious about how you ended up doing user access if not standard PW or Dynamic roles. And what where the factors that made you decide to make your own.

  Reply

  • 

    antti

    • 6 years ago
    • 10

    Sinnut, sorry for the late reply. The UA needs in Sense are very special. They need to be dynamic, based on the values in what member (for example) has in their memberships row. But member can be part of multiple organisations, so we also needed different sets of access rules for same member, depending on what role they used in login.

    So it is very unique and extreme UA scenario we have, and standard PW or Dynamic Roles weren't just flexible and dynamic enough. The system we build isn't as sophisticated though, very fixed into our schema and not something we could release as os.

    Reply

• 

  Roope

  • 6 years ago
  • 21

  Thanks for the great sum up and huge thumbs up to you personally and Avoine as the company for the ground breaking support to PW and Ryan! Wish you all the best for Sense release and can't wait what future will bring for all of us in the PW community - you guys rock!

  Reply

• 

  Alan

  • 6 years ago
  • 21

  Interesting and inspiring in equal measure! Thanks Antti for the article and to you and Avoine for all you have done in and for the PW community (SO glad I found PW back in the when I knew I had to move on from TXP!).

  Reply

• 

  Marty

  • 6 years ago
  • 11

  Thanks for the write-up Antti!

  Reply

• 

  Sevarf2

  • 6 years ago
  • 00

  one word: outstanding

  Reply

• 

  mr-fan

  • 6 years ago
  • 00

  module goes opensource say Thank You Antti & Avoine!! ;)

  This is really great input and make Hooks much more easier to use and understand for newcomers and the handling for all PW Users.

  Best Regards

  Reply