ProcessWire = Framework?

[MatthewSchenker]

Greetings Everyone,

I've been meaning to get into this here, so... I'm getting into this here.

Before coming to ProcessWire, I spent quite a bit of time getting familiar with PHP frameworks. First, it was CodeIgniter, more recently Laravel and Symfony, and Yii. I really like these frameworks (especially Yii, even though Laravel is getting all the attention lately).

However, I can't help but feel that ProcessWire takes care of all the same things that these frameworks do, and it has the core user, database, and other capabilities taken care of. There are still a few actions here and there that I can pinpoint better in Yii or Laravel, but it feels like ProcessWire could definitely close those last few gaps.

Of course, we refer to ProcessWire as a CMF, which clerly indicates "framework." But are my instincts correct in saying that ProcessWire is built on a framework that is equivalent to something like Yii with core CMS capabilities built on top?

Thanks,

Matthew

[Joss]

I Would like to throw a huge, hefty spanner into the works here! (Just for fun)

If you split PW into two piles, in one pile you have the Site directory. Here is, or will be, your CMS. PW gives you a starter, but once you get into it, you are going to build your own content management structure in there on top of the base.

In the other pile is the WIRE directory.

However, this is NOT a CMS, or perhaps even a CMF .... I have a suspicion that it is really a CME - a Content Management ENGINE!

Joss

PS: I have this great want to rename the SITE directory to PROCESS ... just to round off the gag.

[panictree]

@Joss: that's an interesting way to look at ProcessWire. I hadn't thought about it this way, but it makes sense!

[Soma]

ProcessWire core is a framework. And on top of that built a CMS

I think it goes this far

/wire/core

- is the framework

/wire/modules

/wire/admin-templates

- is the admin/cms built on top of the core

/site/

- your site with possibilities to extend admin and cms functionality

You could start now and build your own CMS basing on core.

[MatthewSchenker]

Hello Everyone,

Thanks Soma!

My reason for asking is because, except for a handful of actions, I have been able to replicate everything I was doing with CodeIgniter/Laravel here in ProcessWire.

Actually, on the Laravel forums there are two related discussions about this. If you haven't seen them already, go here:

http://forums.larave...id=21881#p21881

http://forums.larave...?pid=4627#p4627

There is also this:

https://twitter.com/...018610362232832

I find this significant for a couple of reasons.

First, because there have always been three branches of Web development for me:

1. Pure and Naked PHP

2. Fully-Baked CMS

3. PHP Framework

I'm being a bit colorful, but I think you all know what I mean by "pure and naked" and "fully-baked."

Of course, there are CMSs built with frameworks, but I had never found one that maintained the total freedom of the framework while also providing the crucial "engine" of a CMS without making too many assumptions. I know a few that come close. ProcessWire is the only one I have found (and I have tested a very long list of CMSs and framework-based CMSs). The "fully-baked" CMSs are not worth comparing really.

If people in the Laravel community are recognizing that ProcessWire does the framework-based stuff really well, and also gives you those CMS functions every project needs, it's a big story.

Thanks,

Matthew

[ryan]

ProcessWire is a content management framework, which is still a "framework", but more focused on a particular thing. Whereas the framework scope of CakePHP, Laraval, CodeIgniter, etc., is more broad and cover more territory. ProcessWire isn't meant as a replacement for one of those frameworks, but I think there are probably many instances where its focus might make it preferable. And an equal number of instances where the opposite is true as well. There's also something to be said for bringing the two together in some instances.

Another big area of difference is that traditional frameworks enforce a particular approach to build on top of, whereas ProcessWire aims to be a lot more transparent, like jQuery. Frameworks set you up with a place to put your models, views and controllers, whereas ProcessWire puts in you in a plain PHP file (template file) that is given a location context ($page) and lets you take over from there. We think MVC is a good approach to take with ProcessWire template files, but don't enforce anything, as it's up to the developer. For better or worse, the possibilities are wide open in the same way they are with a PHP file on its own… though with a full CMF API at your disposal.

[MatthewSchenker]

Hey Ryan,

Thanks for the excellent explanation!

I see what you mean about the differences between ProcessWire and Laravel. But what's interesting to me is that practically all the goals I've been able to name can be achieved with either a framework or with ProcessWire. Regarding the JQuery approach: after delving deeper into ProcessWire I am seeing the logic of this more and more.

The reason I compare ProcessWire to Laravel is because there seems to be a common philosophy about clarity of code.

I have heard others talk about combining Laravel and ProcessWire. I have come to appreciate both systems, so using them together would be an amazing idea. Can you give an example of a goal that could be achieved in this manner?

Thanks,

Matthew

[MatthewSchenker]

Hi Everyone,

Follow-up question: what's a good way to refer to the ProcessWire framework?

Of course, the whole system is called ProcessWire. Just wondering if, for clarity's sake, we might refer to the framework (for example) as the "Wire Framework," or something like that.

This might seem like a technicality, but my thinking is that it sends a message that there is a framework underlying the system. As ProcessWire gets discussed and blogged about more in the future, this distinction could help convey a degree of meaning to developers and designers who recognize such things.

What's the "official" name?

Thanks,

Matthew

[ryan]

Can you give an example of a goal that could be achieved in this manner?

I'm not familiar enough with Laravel to be able to give a good example. But I'm guessing that if someone used a framework like Laravel with ProcessWire, they would make use of ProcessWire in a similar manner to how you would when using PW's API from a command line script or outside PHP file. You'd use PW for data and the framework for routing. That's just a guess though.

What's the "official" name?

Originally, the framework was just called ProcessWire and the CMS was called "ProcessWire CMS". But I've never given it much thought into formalizing the terminology, but like where you are going with it.

[Joss]

In marketing terms it is a subtle emphasis, to be honest, because when you open the box it is not initially easy to see where the framework ends and where the CMS utilisation begins.

I suppose, as was said earlier by Soma, the admin as it stands is the CMS, since it has some familiar CMS type labels like "pages" and "Templates"

But, if you went and changed the admin and used different terminology, then it would be much less CMS looking.

When it comes to introducing the system, I like Matthew's thought process. Being able to say "here is a core system" and then saying "and here is it implemented as a CMS" is a nice way of laying out the philosophy.

Because from that point it is easy to say "using the CMS tools, you can build your basic CMS enabled site" but then add "and be able to use the power of the core and the API to extend your site in any which way you wish"

So, yes, it can be broken down into two ideas, while being careful to not split the brand, or course.

I don't see why using profiles (and extra admin tweaks) you cannot then create ProcessWire Intranet, ProcessWire Blogging, ProcessWire Community and so on to add to ProcessWire CMS. Just give users slightly different starting points for particular projects to help them find their way in.

[Luis]

My thoughts about pw:

If you just started with pw, maybe you created your First Page and saw how pw Works and handles data you think uh yummi nice CMS.

Well thats fine and correct,pw acts, feels and looks like a CMS.

You then dig deeper into the API, you understand how the different fieldtypes are working and you get a good overview.

You probably think at this point: could I use pw like a Database?

You Set your first page relation, count the arrays and you Play with the Data and you think: WTF!? Is this still a CMS?

The longer you use pw, the deeper understanding of the API, you finally realise which great,strong and powerfull toolset Ryan just handed right into your hands.

At this particullar point the term CMS would not come to your mind anymore.

PW could be used like phpMyAdmin, just create tables,rows and data and work with them, but a Way more easier without even knowig what MySQL really is.

Some of you might know my Intranet Application i'm working on, this is all made with pw and some little template php scripting.

The next days I will Show a Little preview of an App i'm also working on, and yes everything PW driven.

[OrganizedFellow]

Some of you might know my Intranet Application i'm working on, this is all made with pw and some little template php scripting.

The next days I will Show a Little preview of an App i'm also working on, and yes everything PW driven.

I'm looking forward to this preview.

It's always exciting to see what others build with ProcessWire.

[MatthewSchenker]

Greetings Everyone,

When I started this topic a year ago, I proposed that ProcessWire be presented more like a framework than a CMS. Over the past year, as I have developed further with ProcessWire, my opinion has strengthened.

This recent post by Ryan re-ignited the idea for me: (http://processwire.com/talk/topic/5066-creating-commercial-licensed-modules/?p=49389).

It seems that a lot of the discussions around "comparisons" continue to be ProcessWire vs WordPress or vs Drupal or vs Joomla. After working with ProcessWire more, I feel even more strongly that the discussion should shift instead to be more like ProcessWire vs Laravel or vs Yii or vs CakePHP. As Ryan indicates in the above quote, ProcessWire is not comparable to WordPress in what and how you build with it.

I have had numerous situations in recent months where I propose using ProcessWire for a project and explain that it is a CMF, emphasizing the framework part. In my own work, I have already shifted my presentation, describing ProcessWire as a framework. Still, clients start from the perspective that ProcessWire is equivalent to WordPress (and other regular CMSs).

A shift in the discussion might help explain what the system is for, and adjust expectations for new users. It might help us in communicating with clients. And it might attract more attention for ProcessWire from the community of people looking for PHP frameworks but who tend to avoid "CMSs."

Thanks,

Matthew

[Joss]

Depends on the client a bit.

Certainly with my music it is often a case of "look it works, you are selling more biscuits - here is the bill"

I could tell them exactly how my harmonic fifth on the cello adds that sense of pathos that just gives the brand that edge more authority, but you would be amazed how often clients glaze over and pay the bill just to shut me up.

I have that effect on people - very useful.

[teppo]

When a client asks for "a website" with "easy management", explaining that ProcessWire is "an awesome framework for building just about anything" feels plain wrong and is unlikely to yield desired results. On the other hand, when client (or fellow developer) does mention the need for "an application", "framework" or "software platform", it's good to be able to match those needs too.

Personally I really like the fact that ProcessWire has the ability to be both and would like to avoid emphasizing either *too much* over the other. If I needed a CMS, there would be a huge amount of other options available, and if I simply wanted to build an application I could (for an example) turn to Zend Framework and get the job done.. and so on. What ProcessWire brings into this equation is a well-balanced combination of features from both worlds. Each part supports the other, eventually making it more than the sum of it's parts.

I especially love how easy and fast built-in admin makes mocking up data structures -- in fact it's such a smooth experience that the times I've built mock data manually for HTML wireframes etc. have been almost nonexistent lately. I find it faster to make fully functional features using ProcessWire than writing dummy directly with editor. And that, in my opinion, is why it's so damn good.

Not that I really needed to explain it to anyone here, but my point is mostly that I don't see ProcessWire simply as a CMF or CMS or application framework or whatever. It's all of these combined.. and that's a good thing. I hope we don't get stuck discussing which one it is when that question can't (and shouldn't) have one single correct answer

[MatthewSchenker]

Greetings,

Joss: I should emphasize that I'm referring to two different kinds of clients. No doubt, there are the ones who don't know (or care) what a "framework" or a "CMS" or a "CMF" is. I'm not necessarily talking about them. I'm refrrring to the ones (maybe development/design firms, etc) who want and understand frameworks.

Teppo: I agree that ProcessWire is unique in its set of functionalities and capabilities, and like you I would not want to pin it down to one definition. I'm saying that the framework part of ProcessWire deserves to be included in wider discussions where people are comparing PHP frameworks.

Thanks,

Matthew

[DaveP]

It seems to me that there are two different ways to look at this, and from two different perspectives. One is the client/developer relationship, where you can describe PW as anything you feel will get you the job. The other is from the point of view of a new, possibly inexperienced, adopter, where there is a need to manage expectations - PW is not WP or Joomla.

[MatthewSchenker]

Greetings,

Been giving this more thought, trying to find a better way to express it.

Again, based (lately) on Ryan's post cited above, I'm inspired to think of a way to...

1. Highlight the framework parts of ProcessWire without downplaying the CMS elements.

2. Clarify the difference between ProcessWire and other CMSs like WordPress.

3. Put ProcessWire's framework on an equal footing as some dedicated PHP frameworks.

The way I described it in my last couple of points perhaps makes it seem as though I see a separation between the CMS and the framework, and emphasizes "one or the other" too much. I realized this when I read Teppo's last response.

Perhaps it's better to say there's a framework that we can access directly via the API, or we can use the CMS that is also built on that same framework. It's not an either/or situation. There is a core and a continuous expression of that core from the API to the CMS.

I have been spending time with Yii and Cake lately. It seems to me that the ProcessWire CMS (its built-in admin) can be roughly interpreted like the admin created by Yii's Codebuilder.

Bottom line: I'm trying to find a good way to communicate the strenfths of ProcessWire, not just for clients but for the tech community. It should be discussed in the same context as the PHP frameworks we hear so much about.

Thanks,

Matthew

[pwired]

Personally I really like the fact that ProcessWire has the ability to be both and would like to avoid emphasizing either *too much* over the other.

Yes, but there are cases with techy clients where you can not avoid that such a conversation comes on the table. I simply say that the coded architecture of processwire is open for both cms and cmf usage. I show them the api and the unlimited creative usage it allows you with html - api and php.

[MatthewSchenker]

Greetings,

pwired: I agree with you about the continuity between the framework and the CMS, and I do pretty much the same thing when communicating about it, except of course when I have a client who doesn't know or care about CMSs and CMFs and frameworks!

But I am also talking here about the development community. As I said before, I believe ProcessWire should be discused in the same conversations as other frameworks.

There are a lot of frameworks out there. How (and if) they are discussed affects their visibility and adoption. For example, I have spent time with Laravel, and I don't really see that it is generally better than Yii, CakePHP, or others. However, the buzz around Laravel is causing a rapid rise in its adoption within the development community.

Thanks,

Matthew

[Can]

On 18.12.2012 at 0:25 PM, Joss said:

PS: I have this great want to rename the SITE directory to PROCESS ... just to round off the gag.

 Why hasn't this renaming already been made? 

[pwired]

 "site" refers logically to files needed for the website. Isnt the processing done in the "wire" folder ? So I think conventions are already quite alright.

[Can]

conventions sure..but we're talking about coolness

[flydev]

8 hours ago, Can said:

but we're talking about coolness

So /site/ should be renamed to /enjoy/ 

[heldercervantes]

I've been calling it a framework instead of a CMS.

I find that's a great starting point to explain how much different it is from a CMS such as WordPress, how it makes zero assumptions and allows you to build whatever you want without having to hack the S#!7 out of it or depend on a bunch of plugins.

And so far so good. Clients have been trusting my arguments and accepting PW.

Agencies... not so much. They're like christians, and accept only the holy word of WordPress (or whatever they use). They also laugh at me when I say I don't use Bootstrap or CSS preprocessors. Apparently it's a flaw to know CSS enough to not need a crutch to make a responsive column based layout.

I'm drifting. Sorry.