A MODX refugee: questions on features of ProcessWire

[Peter Falkenberg Brown]

Hi Folks,

I spent the evening reading many pages about people leaving MODX for ProcessWire, and also reading data on this website. I'm feeling hopeful that I've also found the New Best Thing, since MODX Evo is end of life, and v3 may or may not be what I need.

I've been using Evo for quite a while, and liked it very much. I built an online magazine site in EVO (http://significatojournal.com) and was very happy with its flexibility. But perhaps it's time to move on...

Before I install ProcessWire, I'd like to ask some feature questions.

- I saw an interview where Ryan mentioned a PW site with 100k+ articles. MODX Evo had a 5k article limit, which I was frustrated with. Is 100k the largest PW site out there? Are there any stats on PW maximum article limitations? Could it handle a million pages? (for example).

- One of the websites I need to build is not a typical website. It will be mostly private, with members each having individual logins (belonging to groups, as well). It will essentially be a large series of calculated data entry forms that will create a series of one-to-many data records in multiple custom tables, with a combination of text and numeric data.

I was originally going to build it from scratch, in PHP, but am now wondering if PW might be able to handle it.

- It will require an entire system of private data forms, lists, reports, etc, that would essentially (I assume) replace the typical manager interface.

One advantange of using something like PW is that the user management is built in.

From this brief description, could PW handle a completely customized interface and application like this?

Thanks for any feedback,

Peter Brown

[Philipp]

Welcome Peter

I will try to answer your questions:

- I saw an interview where Ryan mentioned a PW site with 100k+ articles. MODX Evo had a 5k article limit, which I was frustrated with. Is 100k the largest PW site out there? Are there any stats on PW maximum article limitations? Could it handle a million pages? (for example).

 

First: There is no limit build-in into PW. It is using index-based DB Queries and a Ryan really had an eye for large-scaled sites. I've not that much experience with those large pages, but in my last project I've used arround 4000 single pages combined to a schedule and everything just worked fine. 

There was a thread here in the forums, discussing a site with a million pages. It should be possible with some small modifcations. To gain more performance, you could use ProCache or other modules to speed up the site.

Another larger example from Ryan would be the Tripsite .

 

- One of the websites I need to build is not a typical website. It will be mostly private, with members each having individual logins (belonging to groups, as well). It will essentially be a large series of calculated data entry forms that will create a series of one-to-many data records in multiple custom tables, with a combination of text and numeric data.

 

The user-role-permission system buildin should be able to do this. Have a look at the user and permission section on the API Cheat Sheet

 

The calcutions part should be similar to Luis Web Application Intranet Case Study .

 

I was originally going to build it from scratch, in PHP, but am now wondering if PW might be able to handle it

From this brief description, could PW handle a completely customized interface and application like this?

Yes. As Ryan describes it: Processwire is a CMF or a framework for mostly CRUD Operations in PHP shipped with an adminbackend for a Content Management System (/processwire). But maybe other people here could provide a more detailed answer.

[Pete]

As an ex-MODxer myself who's been using ProcessWire for almost 2 years I can confidently say ProcessWire will handle everything you need.

Much of what you're after are features I've built myself on one site or another with ProcessWire so you're definitely in the right place to build the site you want in a fraction of the time compared to doing it from scratch - once you get going I'm sure you'll be amazed at how fast you can get things built without having to touch a line of SQL or create any custom tables in your database since ProcessWire does that side of things for you

[pwired]

since MODX Evo is end of life.

Hi Peter, such statements are not true anymore since March 19. Modx just released evo 1.0.9., improved and php 5.4 compatible.

http://modx.com/blog/2013/03/19/modx-evolution-1.0.9-restarts-the-little-engine-that-could/

I have to be carefull with my words this time because my last post about modx went wrong.

But here is my view on processwire, maybe it will serve you in some way. When it comes to interfacing, processwire has building blocks for designers, developers, coders and clients. I just love it that you can enter processwire from anywhere you want and start using the skills you already have. It stays closer to the core and doesn't use things like ExtJS and pagetrees but jQuery and pagefields and communicates directly with the database, so it works easy, fast and scalable.

I was originally going to build it from scratch, in PHP, but am now wondering if PW might be able to handle it.

Definitely not build it from scratch, processwire is a huge timesaver compared to that. With processwire you can fill in your own customized php with inline php, functions and modules.

From this brief description, could PW handle a completely customized interface and application like this?

Did you have a look at pw's api ? http://processwire.com/api

Much can be done already with the api

[diogo]

When it comes to speed processwire doesn't use things like ExtJS and pagetrees but uses jQuery and pagefields and communicates directly with the database, so it works easy, fast and scalable.

Just in case this isn't obvious, pwired means that jQuery is used in the admin. PW doesn't enforce any library on the frontend, and you're free to use whatever you want.

[pwired]

Thanks diogo, I forgot to mentioned that.

Here is more to read:

http://processwire.com/talk/topic/1031-thinking-about-switching/

(Post #7)

[Peter Falkenberg Brown]

Hi Everyone,

Thanks for all the timely answers!

If anyone has hard evidence of huge sites (i.e. how many pages) that PW is currently handling, or a solid analysis of capacity limits, that would be great.

=> Also, I read the note about creating directories for every page. Has that been fixed in the newer versions?

Am I correct in thinking that directories are only made for pages *if* there are images, etc, attached to the page?

And... how are those folders managed when a page is moved from one sub-branch (section) to another, or if the friendly url is renamed?

Are the folder names based on the IDs, or the headlines or friendly urls?

Files for the pages themselves are not created are they? (i.e. static pages?) The pages come from the database, dynamically served?

(Sorry, I haven't read through all the docs yet.)

I really liked the function in MODX Evo where you could move an entire branch to another parent. Of course, the image assets were

handled differently.

I'm getting more and more interested in this program. .

Thanks for your answers.

Peter

[Philipp]

I think the latest version stills creates a folder for every page. But there is a module that fixes this behaviour if you have problems with those folders.

You don't have to think about the folders when moving a site. They are namend after the unique page ID, for example /site/assets/files/<pageid>/myfile.png . The folder name might not be "friendly" but your file name remains the same as uploaded (a second file with the same name would get a number). 

Alles pages are "rendered" when a visitors visits your site(so PHP and the DB is involved). You can purchase Ryans ProCache module. This generates static files and speeds up your site. It really configurable and works perfect with the PW build in functions like URL Segments or Pagination.

[Peter Falkenberg Brown]

Dear Philipp,

Thanks, I'll explore this further.

If anyone has any more hard data on the maximum page capacity, I'd love to see it. Maybe Ryan has the best handle on that?

I found it fascinating that Ryan programmed bulletin board systems (bbs's) in the '90s. Does anyone remember those? I wrote a private, nonprofit BBS in '93, in a scripting language called "Pro-Yam", which was written by Chuck Forsberg, who wrote zmodem. I don't run across many people who have worked with BBS's anymore.

Best regards,

Peter

[apeisa]

We have one site with approximately 100 000 pages and runs nicely. That is because we use discussions module which saves forum replies as pages.

I don't know any hard limits on page count, but I also don't believe anyone has taken it to millions yet.

[diogo]

I found it fascinating that Ryan programmed bulletin board systems (bbs's) in the '90s. Does anyone remember those?

chhhhhhh... you will wake up Joss and Mathew

[ryan]

If anyone has any more hard data on the maximum page capacity, I'd love to see it. Maybe Ryan has the best handle on that?

There really is no maximum page capacity. If MODX Evo had a limit on quantity of pages, then I'm guessing they were keeping some reference to all pages in memory at once. We don't do anything like that with pages, so any limits have more to do with the server itself… mysql, disk space, file system. I don't see any reason why you couldn't have millions of pages in ProcessWire. 

I found it fascinating that Ryan programmed bulletin board systems (bbs's) in the '90s. Does anyone remember those? I wrote a private, nonprofit BBS in '93, in a scripting language called "Pro-Yam", which was written by Chuck Forsberg, who wrote zmodem. I don't run across many people who have worked with BBS's anymore.

Chuck Forsberg and ZMODEM, good times. The BBS I ran was Data Connection BBS between 1989-1995, and wrote software called DataView for viewing inside ZIP (and ARC, RAR, etc.) archives online. Also wrote a software called Oneliner …kind of like Twitter for BBS times.

      __ \       |           __|                      |  _)
      |   | _` |  _| _` |   (    _ \   \    \  -_) _|  _| | _ \   \
     ____/\__,_|\__\__,_|  \___\___/_| _|_| _\___\__|\__|_\___/_| _|
     RENAISSANCE WHQ, FUTURE CREW, LEGEND DESIGN, IGUANA, EMF, PRIME
     -
     Node 1: (703) 506-8598 - 16.8k HST DS v.32bis
     Node 2: (703) 847-0861 - 28.8k HST DS v.34
     -
     Sysop: Ryan Cramer [Iguana/Renaissance]
     Located in McLean, Virginia, USA
     Online since 1989
     No Lamers (had to say that =)

[Peter Falkenberg Brown]

Dear Ryan,

My four children can't even relate to the concept of a "BBS". "BB What? Does that come on the new Galaxy phone? Huh?"

But just wait. Their children will say, "What do you mean, 'cell-phone?' You mean you don't have a wall in your house that turns into a 3-D viewscreen for phone calls, that makes it look like the other person is sitting in the room with you? How quaint."

Peter

Dear Ryan,

Oh; and thanks for the stats about the millions of pages. I'm *very* encouraged about PW!

Peter

[ryan]

What's interesting to me is how similar forums like this are to the way BBSs were, at least with regard to the community aspects. Though with many good BBSs, you always had to redial dozens of times before you could make a connection, so you really had to be committed. In my case, I was sometimes spending a couple hundred dollars a month connecting to BBSs in Europe (like Future Crew's Starport BBS in Finland) to download the latest demoscene releases to distribute them in the US. It was a costly hobby.  

[Peter Falkenberg Brown]

Dear Ryan,

Yes, redialing BBSs... I remember that. A long time ago, far, far away.

Peter

[Nuwanda]

My first post here, coming from mainly Wordpress. The holy grail for me is exactly the description below:

 As Ryan describes it: Processwire is a CMF or a framework for mostly CRUD Operations in PHP shipped with an adminbackend for a Content Management System (/processwire).

That's really it, isn't it?

For years I've been stuck between the lightweight PHP framework (like Codeigniter) versus full-on CMS (like Wordpress) thing. The former requires a lot of monotonous coding to get an api + admin set up, and the the latter gets you bogged down in superfluous features.