If you had to use another system....

[apeisa]

I was a bit confused between what was Silverlight and what was the framework but will check out the new version 3. Is it a goos system? Kirby looks interesting, not sure what the implications of no db though are?

I haven't used Silverstripe, but heard some good things. I have always found it little bit "overhelming", though the new UI seems to make it much cleaner experience.

About Kirby: there is admin panel available: http://getkirby.com/docs/panel Using files only has some advantages too (mainly very easy versioning with git/snv etc). I wouldn't consider Kirby with anything too huge, but I see that as an interesting and refreshing alternative - taking the "simplicity" to extreme (even compared to PW).

it seems somewhat Processwire-inspired too!

I don't think so. Both mimick the jQuery API to CMS field and use PHP, that is where the similarities come. Also both have settled to use $page and $pages variables, which make them seem even more similar (both I think $page is only logical variable name there.. $node..? $entry..? no no). And since Kirby's roots are in year 2009 (http://web.appstorm.net/general/interviews/interview-meet-bastian-allgeier-the-developer-behind-kirby-and-zootool/) and open source PW 2 came out December 2010 (I think?) I don't think they have drawn much (if any) inspiration from others. Cannot say for sure though.

[onjegolders]

Thanks Apeisa, some really interesting and helpful suggestions. I really am not looking to leave Processwire behind, it is by far the most intuitive, logical and friendly system I have used, I'm just aware that I need a bit more of a power-solution for when I need some extra functionality and I don't have the time or know-how to hand build it.

I may have to reconsider dropping Drupal. I could definitely work with it, it's just theming is such a huge waste of time I'd probably use someone else's which is not something I'd ever have considered before...

Will check out Silverstripe and ModX a little more though but can't wait to get back to my PW projects!

[slkwrm]

I would stick with PW, really

I remember getting dizzy when I had to make pages in Drupal look the way I wanted:

Where this margin is coming from? Ok, this module generates this HTML with 4 wrappers. Where it takes its css from? Let's see it has cached css-file which is generated every time I save module settings. Ok, let's take a look at its real css-file. Well, it's not really css-file, but css template written in php. Ok, what we see, it generates css depending on the options we set in module's properties, but I still can't see where this margin is set. I've spent already about 20 minutes trying to find this goddamn margin property. Ok, if it isn't here it should be somewhere else, let's dig through module's source files. Haveng spent another 10 minutes looking through module's source files I finally found this margin in module_name_API.php!!! WTF? Why put it here? Ok, I fixed my margin, but I have another page where this module's markup is output next to another's and now they overlay, because that another module generates its own markup and now I have to repeat this crazy procedure again for another module. No, not anymore! I have a lot of other things to do!

Yes, Drupal is very powerful, but this continuos, never-ending hacking makes me suicidal I would rather spend time creating using the system then struggling with it.

As for MODx, I really liked Evolution and still do, but PW makes it look unnecessary complex and is light years ahead in terms of intuitiveness and flexibility. I also tried to use Revolution, but to me it over-complicates things and I can't stand its sluggish back-end (thanks ExtJS). Their announcement IMO is pretty logical step to take as Revolution haven't equaled the hopes, but it gave really good understanding of what's really important for this CMS. I wish MODx team good luck with MODX3 because they've already made one of the best CMSs that I really like and just because they are great guys. Wish them to repeat their success with third version.

Processwire brings joy to development, this is why I will keep using it It makes me learn and create rather then hack. And it has a brilliant community, in life of which I wish could participate much more then I do now.

[diogo]

Thanks Diogo, I actually looked at pyro before Processwire as it was CI based (I believe) but was put off by a lack of support, lack of a good community like this one

Do you have a different experience?

I don't, I didn't use it more than installing and having a look at it. And this was before I met PW, when I was still in the process of choosing a CMS to work with. But it does look interesting. Ya, I heard about the community not being very friendly.

I back what was said here by others. At this point I'd rather spend my time learning PHP to start building modules and helping with the evolution of PW, then learning another CMS.

[onjegolders]

Thanks again, I'm definitely not going anywhere! But I really am not a developer so I will try and help by spreading the word and trying to help in the forums any way I can. I'm really hopeful that having such a solid foundation, the talented guys around here continue to make useful modules that extend the possibilities for guys like me to use it for more and more projects.

I also think as long as Ryan is around, PW is in very safe hands

[onjegolders]

OK, after lots of research, this video has made my mind up for me

Think the PW community needs to hire him

[SiNNuT]

Hahaha, that video is great!

[ryan]

it seems somewhat Processwire-inspired too!

I think more likely we're both inspired by jQuery. However, it is possible they took inspiration from PW on their API. I published the very basics of the ProcessWire API in 2008 here. Then I emailed it to a few CMS authors, hoping someone would take interest. This was at a time when I wasn't yet sure if I wanted to pursue making ProcessWire 2.0, or joining another project. So I tried to put some stuff out there to see if anyone took interest. I got no interest from other CMS authors (at least not that I knew of), but got a lot of interest from other web developers (users of CMSs). So that's one reason why PW 2.0 open source went forward.

[Pete]

I moved from MODx to PW and wouldn't want to move back.

Don't get me wrong, MODx (Evo) was a great tool and really useful, but to do anything more complex you have to learn their markup and terms whereas PW doesn't force you to work any particular way.

As such, I suspect all of my MODx sites will eventually be moved to PW - the point they make the switch for each will be the point at which being on MODx becomes a restriction (at present, they work so if it ain't broke...).

Sorry, I'm not adding much here but since the only other project I currently work on is an intranet system that's home-grown and I can't think of another system I'd need to use besides PW for everything else.

That said, I'm getting into Lemonstand for an e-commerce site at present. It's a little bit of a learning curve as they don't have a cheatsheet (ever project should have one since I'm so reliant on Soma's ) but there is great flexibility to be had behind the scenes. They could do with changing their coding to a jQuery style (because I'm lazy) but aside from that if it doesn't have what you need it's easy enough to program something, as well as being easy enough to create custom calls to the database.

[onjegolders]

Thanks Pete, yeah I've been looking into any system which may offer me a little bit more of a helping hand with added functionality. ModX was one such system which has a bit more in the way of addons but I found the system and syntax to be confusing and I just felt like I was stuck in a Microsoft 1990s time-warp.

The only real reason I'm looking around is that whereas most people here may have the skills to make their own modules or extend the core, it's not really something I'm remotely capable of (at least at the moment anyway). So I can build 10 times more efficiently with PW to an extent and then I hit a bit of a wall. I'm sure with time, more modules will come along, there just isn't another system out there that can touch Ryan's amazing API.

Haven't checked out Lemonstand yet but call on Soma's cheatsheet, a fantastic tool!

[DaveP]

<offtopic> I can't read 'Lemonstand' without thinking 'lemonparty' and shuddering.</offtopic>

[ryan]

The only real reason I'm looking around is that whereas most people here may have the skills to make their own modules or extend the core, it's not really something I'm remotely capable of (at least at the moment anyway).

This is something that a lot of us do because it's fun, not because it's something that we have to do. We might make a module so that we can do something like this because it's fun, satisfying, and efficient (plus it looks good) …

echo $pages->find('brand=/brands/audi/, mpg>25')->renderCars(); 

But the reality is that it's also not necessary. You could perhaps more easily just package it into your include file and do this:

$cars = $pages->find('brand=/brands/audi/, mpg>25'); 
include("./render-cars.inc'); 

And in your render-cars.inc:

<?php
foreach($cars as $car) {
   echo "<p>{$car->title}: {$car->mpg} mpg</p>";
}

What I'm trying to get across is that much of the things we all create and use modules for is optimization and fun. Perhaps others feel differently, but in my case, most of my sites don't even use any modules other than what comes with PW. I create modules when I want something I can re-use on multiple sites or share more easily with the PW community.

Another point about modules is that they are a whole lot simpler than you would ever imagine, once you get going with it. But the lack of ability to create modules is not going to limit your ability to use ProcessWire in any way. You can make it do pretty much anything without having to even know about modules. But when the time comes that you become interested in it, it will only increase your enjoyment of development. So when you see what appears to be complex development conversations about modules and such, don't worry. What you don't know isn't going to hold you back in ProcessWire. It already seems like you have a really good understanding of development and using ProcessWire. Based on your past posts, I feel confident you can push ProcessWire to do what you need when you want to. And we're always here to help with questions and problem solving.

If I were you, I would keep using ProcessWire for everything that you are comfortable using it for. When situations come up that you feel can't be as easily solved with ProcessWire, then investigate services like what Pete mentioned (Lemonstand, Shopify, Google, Facebook, Flickr). There are services out there for nearly everything and this is where a lot of functionality is trending. For instance, look at the quality of a comments service like Disqus... it makes you wonder if we aren't far off from the time when built-in comments are no longer considered a required core feature of CMSs. When we had to setup a forum for ProcessWire, I never considered trying to create it myself in PW. Instead, we went with SMF, and then IP.Board. Services like these and others are better than what you can reasonably expect to build on your own, or what you could expect to come with (or be added-on to) any other CMS.

Honestly, if you use ProcessWire and then utilize services for the things you don't want to build, then you will be able to do everything you could ever want. And more quickly, more securely and easier to support, than if you were trying to leave it all to a CMS. For the rare cases where you need something that won't be easy to do in PW, and your service options are limited, then bring WordPress into the mix. Not that WordPress can do much on it's own, but it's following is so much bigger than anything else that literally every possible thing has been coded for it. I certainly wouldn't want to use WordPress as my CMS, but I have no qualms about pulling it in when something that I need is available as a WordPress plugin. You aren't going to find any other CMS that has as much 3rd party stuff built for it. WordPress is easy-enough to figure out in a day (from a development perspective) that you also won't find yourself as frustrated as in Drupal (at least, this was my experience). It's not much prettier than Drupal from an output generation perspective, but it will be much more respectful of your time.

[yellowled]

What I'm trying to get across is that much of the things we all create and use modules for is optimization and fun. Perhaps others feel differently, but in my case, most of my sites don't even use any modules other than what comes with PW. I create modules when I want something I can re-use on multiple sites or share more easily with the PW community.

Wordpress and Contao are examples for what can happen to a CMS (or blog engine), if it gets too many modules or plugins – every tried finding a good contact form or lightbox plugin for WP? Good luck with that. It'll cost you days.

Modules are great for non-expert users (which is why a blog system like WP is more likely to have a lot of them than a "real" CMS), and I admit that there are things I couldn't do in PW in a reasonable amount of time without modules. But in case of simple stuff like a lightboxed gallery, I prefer to have a CMS emit the markup I want and use the lightbox script I want instead of using a module which never seems to emit the code you'd want it to.

I'm not sure this "module proliferation" is something you can control beyond a certain point of growth of a CMS or blog system. But as long as it's possible, "one module/plugin per purpose" is something a CMS can really benefit from. I would like to see PW's users adapt such a philosophy – if you intend to write a module, first take a look at the existing modules and see if you can extend one instead of adding (maybe duplicated) functionality via a new plugin.

[onjegolders]

Thanks Ryan for another great post.

For what it's worth, I'm thinking more along the lines of publishing, groups and the sort of things that could be added to the backend rather than an alternative to the excellent API.

As Yellowled says, if we're talking about a gallery, I feel much more comfortable, coding it myself with the help of colorbox or equivalent JS script and I think having one quality module for each purpose is far preferable than having 700 à la Wordpress.

I think some things like forms (which is coming), the odd social integration plugin, perhaps publishing workflow would, and will hopefully in time, strengthen this great system further.

As Ryan says so well, PW was not built to be all things to all men but to be the cleanest, most efficient way to handle most tasks.

Perhaps, with the talk of the web moving towards more specialist services, we can look to use a few "packages" in the future (like the blog one Ryan has posted) to help kickstart certain projects yet keep hold of the lean core.

Thanks again for being such a great and responsive group of people

[diogo]

"one module/plugin per purpose" is something a CMS can really benefit from. I would like to see PW's users adapt such a philosophy – if you intend to write a module, first take a look at the existing modules and see if you can extend one instead of adding (maybe duplicated) functionality via a new plugin.

I totally agree with this. I even think we should take this as concept for PW. I really like the way things are happening here. Most modules are discussed in the forum, and each module gets lots of input from the community before it's finished. I know that it isn't easy to keep it like this, as the number of users and developers grow, but would be great if it would be possible to keep a truly useful official modules repository (not too big, and without repeated functionality). This could be done via the forum, and via a small number of administrators who would filter, and propose the merging of modules with the same functionality.

[Pete]

I agree diogo - a lot of other systems seem to have half a dozen gallery modules for example and not all are great galleries or offer different functionality that could be merged together into amore coherent module. In those cases and others, expanding on existing modules (whenever the author doesn't mind) would be preferable than reinventing something completely.

For example, if someone creates a gallery module with a specific lightbox script and someone wants a gallery with a different lightbox script, it could just as easily be implemented by altering a few lines of code and adding it as a configuration option.

Also, it often (though not always) turns out that as modules grow in this way with several developers pushing things forwards you end up with a much more mature piece of code as a result.

Of course, that depends on whether the devs can agree, but that's where version control and Github comes in with the original author retaining overall control and merging changes to the source

[apeisa]

Of course, that depends on whether the devs can agree, but that's where version control and Github comes in with the original author retaining overall control and merging changes to the source

And if they don't agree, it is just a new fork or a complete rewrite. I think that "duplicate" modules will inevitably happen and I don't see it as a bad thing only. We wouldn't have a PW, if Ryan would have settled to the idea that world doesn't need another cms. What we do need is that our "modules section" will scale and help to provide good information about each module, so that finding best possible "gallery module" would be a breeze.

[Pete]

I think you've made an excellent point there - as long as it's easy to find the right module, we won't get near-duplicate modules appearing unnecessarily. Similar modules should theoretically only appear when there's a good case for them to be made, such as a different specific use or something like that.

[SiNNuT]

Just as a little side note, i quite like the way the laravel framework presents their 'bundles' section. Of course, this could be modules as well.

http://bundles.laravel.com/bundles/'>http://bundles.laravel.com/bundles/

http://bundles.laravel.com/

[Michael Fillier]

A lot of good points here. One of the reasons I moved from Joomla to Drupal was because of how modules were handled. Joomla had tons of modules that all achieved nearly the same thing, this was no doubt a result of actually selling the modules. Developers are pitted against each other, in order to make you buy their product. I understand that competitiveness can lead to better products, but overall I just see it being a waste of effort. On the other hand Drupal is completely different in the sense that it is rare to find duplicate modules and they are FREE!

I like that PW modules are hosted on git, but I think you should have separate pages on the PW site for each module, with a link to the git source. One thing I like about Drupal's site structure is that I can find any module via url by going to drupal.org/project/{module_name}. This makes it easy for me to lookup a module at any time. In addition, Drupal's "Issue Queue" is one of the best ways to get help with a module or find a solution to a problem. I am getting the point about PW's approach to minimize markup generation (took me a while). As I wrap my head around the possibilities for creating brochure sites, allowing me to design them my way, I really like it. Drupal's do-everything approach is great, but I don't find myself building sites that require "everything".

[Pete]

A modules section is planned for the new website, so that should help

[onjegolders]

Just wanted to say that with the speed (and quality) of module development lately by the community and with the addition of Ryan's Form Builder (and a few profiles on the way) I really feel like there is less and less need to consider alternatives to PW for most projects.

I'm so happy with the way things are moving, the API has always been so strong and gradually some quality additions are appearing that are just going to take this system to the next level.

Once again, a big thanks to Ryan (+Apeisa, Soma, Diogo, Pete, Nico, Wanze and so many others) for all your continuing hard work! I'm excited by where PW will be in 12 months time!

[GuillerOnLine]

Sorry for my English

I'm glad I found this thread and understand the idea of ​​Processwire CMS, although I was looking for a CRM, a great job, I'll give it a try for my next site.

I think it's good to get away from the old concept of Drupal, and is best guided by the newest, such as http://parsimony.mobi/ which is still in beta, now I have to do an intranet, pricing, ordering, cash ...

Maybe I'm wrong and you are on that path, something like a module to generate modules in processwire or already have?.