ProcessWire Dev Branch

[ryan]

It seems to be something to do with the 3rd-party modules I didn’t uninstall. It’s a multi-language site with the Textareas profield. Any pointers would be greatly appreciated!

@Jan Romero: What version of PHP and MySQL are you running? You also mentioned 3rd party modules–which modules? (If not Textareas ProField?). The ProFields have been developed in tandem with the dev branch, so I'm fairly sure that wouldn't be it. But the commit you indicated did change the way module information is cached. I found one other instance of a similar upgrade error and we traced it to a bug in a specific PHP Version. That's why I'm curious about the versions of software you are running. 

Small drawback: PW is getting bigger (file-size), even without the new Languages and Iridium profile, or the new additional admin-theme.

I think this is largely the inclusion of CKEditor. The Iridium profile does take up some space since it has a lot of photos, so I may leave that one as an external install. Overall though, I think we're being pretty safe with file size. I can still download a ZIP from GitHub in less than 3 seconds, and we've never had any complaints that file size was preventing someone from trying or using PW. As a result, I think we're better off using file space where we can to make sure PW really impresses people when they download and try it out. On the other hand, we should also be safe and not include multiple RTEs, etc. For example, we removed TinyMCE when we bundled in CKEditor. 

What I'm really missing and waiting in PW since the beginning are draft/live versions of pages, basicly more advanced workflow/publishing options. I feel this would be a lot more needed than all the new features we got. Not saying they're bad. I hope we get that with 2.5! 

There has been little demand for this, that's why it keeps getting pushed back. How many threads do you see posted of people asking for this capability? I agree it's a nice capability, and I would like it too. But I try and focus my efforts on what will get used the most. At least the non-sponsored new additions you see in 2.5 are largely based on what's been asked for repeatedly in the forums (as well as what I would personally find useful). So we'll count your request here as momentum for drafts.

The funny thing is that PW1 had full drafts capability, had a huge amount of work behind it, and it worked well. The unfunny thing is that clients rarely used it. The primary time that clients (my clients at least) wanted a draft of something was when creating a page. That's why we've already got that in PW2. I ended up feeling that all the work behind drafts in PW1 was kind of a waste of time. Of course the PW2 user base is much larger and the potential audience for such a feature is much larger now. I personally would like to have drafts for already published pages too, but the reality is there's only a small segment that will actually take advantage of it. It's a feature that sounds good, but few use. Still, we may have the critical mass now for it to be worthwhile. And it's also on the checklist of many, even if they won't use it. I even have it mostly built already, and have been occasionally working on it, but it's been kept in the background as more popular features have gotten attention. 

I just guess we could crowd-sponsor our own desires ))

I appreciate the interest of course, but I don't think this is necessary. We've already got commercial modules funding developing of ProcessWire. The focus on what gets added is also largely based on what are the most common needs people have around here, within the limits of feasibility and schedule. 

[Martijn Geerts]

I do agree here with ryan about the draft capability. We have already unpublished. Extending this with draft functionality may lead to more confusing for editors working with relative small sites. When drafts gets to the core, I prefer that draft are turned off by default.

For the add pages menu. I wish that it would be better configurable. Sites that I build are usually more complex then the average websites. It's rarely that I can use the add page button. So have to turn it off on every template. I wish I could find templates/pages my self to get add to this menu.

[Raymond Geerts]

Just installed PW 2.5 (or 2.4.15 as shown in the admin footer). I'm very happy with all the new features. Also nice to see a site-blank profile. Going to give it a try and see what new stuff is under the hood.

[horst]

I do agree here with ryan about the draft capability. We have already unpublished. Extending this with draft functionality may lead to more confusing for editors working with relative small sites. When drafts gets to the core, I prefer that draft are turned off by default.

This draft capability, would it work that way that when you edit (add/remove and /or rearrange) images on a page that is already published that these changes are not directly visible at the frontpage? This one is really odd and need some better handling IMO.

[Jan Romero]

@Jan Romero: What version of PHP and MySQL are you running? You also mentioned 3rd party modules–which modules? (If not Textareas ProField?). The ProFields have been developed in tandem with the dev branch, so I'm fairly sure that wouldn't be it. But the commit you indicated did change the way module information is cached. I found one other instance of a similar upgrade error and we traced it to a bug in a specific PHP Version. That's why I'm curious about the versions of software you are running.

Thanks for the reply! I don’t know exactly what the problem was, but I think I got it running. I var_dumped through modules.php until I found the place and the module that were causing the problem. Thankfully it was only the fourth or fifth module (LanguageSupportPageNames). The point where it broke was if($module instanceof Module) in getModuleInfo(), so I added a condition that called getModuleInfoExternal() specifically for LanguageSupportPageNames. With that, PW ran fine and built the module cache. Now I’m running the unmodified wire folder without any problems.

I’m guessing it was something I caused, though I’m not sure how. My PHP version is 5.3.28.

The upgrade is great, by the way. I’m acting very ungrateful here. Really, I couldn’t be happier with ProcessWire

[clsource]

This draft capability, would it work that way that when you edit (add/remove and /or rearrange) images on a page that is already published that these changes are not directly visible at the frontpage? This one is really odd and need some better handling IMO.

I think you can achieve a similar behaviour using pages and some module that merges the changes.

Like you have page A on production. You need to change A but push the changes later.

Create a Duplicate unpublished page A, commit changes and merge A with the duplicate.

I think some module could do that.

[onjegolders]

Ryan, a huge thank you for all the recent changes. The speed of the development at the moment is very exciting. I also think you have a "knack" of prioritising what's important and I very much trust your vision for the future.

I think the drafts module is a nice idea but perhaps something that can be a funded, 3rd party module rather than part of the core.

I wanted to point out on the version I'm testing (2.4.15), when you choose whether a template can have children/new pages, the fields below stay visible, whereas they used to collapse as appropriate, not sure if this is intentional (it's certainly not a big deal )

[Soma]

@ryan. Not a lot of demand? What planet do you live

Well, everytime this comes up it get's many likes. My post just got 7 likes.  

I and many others are waiting for versioning/drafts since a long time. Thing is that it was on the roadmap all the time, so many of users are not asking for it again and again cause it's already.. well "ordered".

I agree that it might not be always needed, and I see that this is not a quick implementation (I wouldn't know how in PW this should be designed). Maybe PW just isn't designed and capable for such a feature. And also it can lead to confusion if not implemented right. And all that comes with it, all correct.

But I think it's a feature many are waiting for. 

[felix]

+1 for drafts. That's something i consider essential (and the only thing that im REALLY missing in pw) for every cms (and I can't think of one that hasn't got this feature apart from pw)!

Almost EVERY of our customers asked if they can preview their edits or schedule changes to an exisiting site to be published at some later point.

In the roadmap I can see all the cool features are sponsored by someone. I just guess we could crowd-sponsor our own desires )) If it was possible to estimate, how much will it take to complete those "draft and live versions of any page" functionality, we could try to collect the money and get the common good. Just recently I took part in such an endevour related to Joomla. I can't say I got too much money to spend, but I'll surely find 5 to 10 bucks at least . It would be cool to see stated "this feature is sponsored by community". To not break Ryan's open source spirit down we could decide to sponsor definite amount of new functions per semester or so. We could also make some kind of voting on that, so we really take part in deciding, in which direction should this software develop. What do you think?

[pwired]

Not an expert here but will this draft integration have any influence on the speed in the core ?

[SiNNuT]

I do agree with Soma that over time there have been quite a few users that expressed their (big) interest in PW (page) versioning capabilities. On the other hand it's also quite hard to estimate how many PW clients would actually go on to use it. But a killer feature nonetheless, if done right.

Anyway, it's on the roadmap for 2.6+ and if it stays there, i personally think it might be a good thing if the versioning, enhanced workflow and js session monitoring became a priority after 2.5. Why? Because i think these 3 items kinda go together. In my mind a versioning system really has the most use in some kind of editorial cycle where multiple people can work on a document (page) and maybe put versions up for review and approval, or other workflows. Ideally this would be be accompanied by a way to compare differences between the published version and/or draft versions. Maybe some inspiration can be taken from the VersionControl module by teppo.

But maybe i'm taking this too far. I would be curious how Ryan sees the scope of versioning capabilities and related subjects.

[Ivan Gretsky]

I think SiNNuT is right and it is all about workflow in the end. This is something really needed by an enterpise CMS.

[ryan]

Some more updates on the multi-language front:

ProcessWire now comes with a multi-language site profile

Language translation files now split by site and core

These are the last two things I'd wanted to add to PW 2.5 before release, so please consider it now in release candidate stage. Your help testing is appreciated and please us know if you run into anything that's not working. 

I agree that it might not be always needed, and I see that this is not a quick implementation (I wouldn't know how in PW this should be designed). Maybe PW just isn't designed and capable for such a feature. And also it can lead to confusion if not implemented right. And all that comes with it, all correct.

PW is already designed for such a feature and has been since the beginning. Development of PW2's core and development of PW1's draft system had overlapping timelines. I had planned on including drafts of published pages in PW2 until I saw how little use they got among my clients at the time. In PW2, page IDs 500-900 are reserved and recyclable/reusable for drafts, and there are already methods in the core and Fieldtypes that are there to aid in managing drafts.

PW's unpublished vs. published pages system already accommodates the biggest needs in drafts. Drafts and unpublished pages are essentially the same thing in the minds of most (of my clients at least). The drafts that you are talking about are something different and really only useful in situations where you've got pages on a site that continue to undergo major changes after they've already been published. Since developing the drafts system in PW1, I've learned that most don't publish content that way. Instead, they work on something, publish it when they are ready, then move onto the next thing. Though drafts for published pages are definitely useful when/if that is the need, and I have no doubt that some clients have the need. But the reality is that it's a whole lot of overhead for something that most won't ever use. As a result, it would likely come in the form of a module (whether uninstalled core, or 3rd party I'm not sure). But it's definitely coming. 

In terms of technical challenges for drafts of already published pages, they are only with regard to Fieldtypes that create other pages. Specifically: Repeaters and PageTable. Those two Fieldtypes are the only two I'm aware of that don't currently support drafts for already published pages (though it's possible they could with modifications). All the other Fieldtypes are pretty much draft-ready. 

Not an expert here but will this draft integration have any influence on the speed in the core ?

Technically there is significant overhead associated with drafts of published pages. It's a 2nd set of editable data. However, you wouldn't feel the effect of it unless creating or publishing a draft, and specially one that had a large amount of assets connected with it. As a result, most would likely not feel the overhead. In terms of comparing overhead, repeaters have more overhead than drafts. 

But maybe i'm taking this too far. I would be curious how Ryan sees the scope of versioning capabilities and related subjects.

I'm very much sold on Teppo's versioning system, and I use it on pretty much everything now. While I have plans to finish the drafts system that's already started, I don't have plans to reinvent what Teppo has already done with regard to versioning. If people have more needs in terms of versioning, we should probably talk to Teppo.  

[Pete]

I had written a big post here about drafts/versioning etc a few days back but silly me was doing too many things, forgot about it and forgot to hit "Post"

It went a little something like this:

Drafts/versioning/workflows (let's just label all of those as workflows because they are all linked) is a feature that is usually required by larger sites/companies and is something that is actually worthy of the name "enterprise" that people have been using a lot recently.

A system that I used 10+ years ago when working for my local Council had the following abilities (not saying we're behind the times by mentioning "10+ years ago", more that my memory won't be great when recalling the details ):

The web team manager was able to edit certain fields (META data etc whilst the rest of the team was able to edit the content fields. This can already be accomplished in PW, but not sure how easy it is to use - ideal would be a tab when editing a template that has a matrix of all the fields and all the roles and checkboxes to determine who can edit/see which fields.

Once web team user has finished editing, page goes to approval with team manager who can review the edits. These will quite often be changes to pages that exist already, so this is a draft copy of that page that has been worked on.

There were also X past versions of a page (in PW this could perhaps be determined per-template again as some may need no drafts and others you might want a few) along with who edited them I think (10 years is a long time).

Pages could also have a review period assigned to them. This would be a trivial module to build in ProcessWire, but the concept was that you would assign each page a review period of 6 months as well as the email address of the person best suited to review the content - this is NOT always a user account in the CMS. In the Council where I worked this person could be another department head and they would receive an email for each page on the relevant review date, with follow-up reminders. The ideal here would be for the web team leader and other suitable people to be able to log into the admin and see a list of which pages were up for review, who they were being reviewed by and they would remain in the list until either the content was updated or a box was ticked to add another X months to the review date.

In theory there are multiple workflow steps that might be required - I think Concrete5 has the ultimate workflow solution here (I started the video at 40 seconds but not sure the forums will cope with that ): http://youtu.be/Z1fHz5jTnw4?t=40s but I'm not 100% sure a "version 1" would need to be that fancy. I can see how the interface might start to come together though as we already have things in the dev branch at present that deal with triggers and actions, I think something like that could be applied to per-template workflows.

There isn't a huge audience asking for this, but there is a huge potential audience out there. The vast majority of medoum-large news/magazine sites could use this - having run a small one as a hobby it can become problematic to keep track of what's going on with just a handful of staff. Then there's just about every local government who are on the lookout for something powerful and cheap, but have to have the workflows in place for accountability (and sanity when dealing with lots of staff editing bits). And then there are large companies with lots of content to manage. Certainly I can see all of the above wanting to use ProCache too since systems with advanced workflows can often be of the slower variety.

I don't want to sound melodramatic, but without a good, coherent approach to drafts/workflows/version control we are effectively shutting out a large audience. The problem is that it is easier for people reviewing a CMS to see what it's got, not find what they want and go elsewhere rather than saying "I'd use this CMS but it doesn't have feature X", so we will never know how many people might actually consider PW if it had workflows.

(On a related note, can we set up the Site Search feature in Google Analytics for the forum and site search fields ryan - then we might get a better idea of what people are searching for but not necessarily requesting ).

[ceberlin]

We have the same experience as Pete. This is my scenario with larger teams:

"draft" means: needs to be finished and approved: the editor sets the page up but has no right to change the status. The supervisor approves by changing the status. 

So, "draft" clearly says: not ready, work needed. (As a workaround I use a checkbox field for that at the moment.)

"unpublished" means then: content is ready but for other reasons the page is not live (like a campaign/news with a start date and an end date).

[-aj-]

I think that editing and content approval workflows are a great idea and I can 100% see the use case for them in enterprise application and large workflows. 

I don't think it should be part of core however. Keep core as lean and abstract as possible, not catering to any specific use case over another. 

These features would make an excellent module, or possibly multiple modules that work nicely together around each other such as page/node statuses, page/field version control, editing/approval workflows etc. Having them as officially supported/vetted paid modules would be the ideal scenario if you're trying to attract enterprise customers. 

WordPress gained a lot of larger publishers when it worked heavily on workflow / editing flow improvements (officially sponsored by Automattic as part of the WP.COM VIP program), but this was still done as a plugin because it's more than the average user needs, heck post versioning as it exists today in WP is likely WAY over the top for 99% of WP users and it just bloats the DB. 

[Ivan Gretsky]

Thanks, Pete! That is a good explanation of what I meant under "workflow" (and the video shows really good, how it could be implemented). Surelly drafts only won't do the whole workflow job, but they could start it. Granular per field/tab permissions are another step.

And just wanted to add that this feature is not only needed for larger sites, but is really usefull for all of them if you have more than one person working in the team. We have SEO person doing metatags, we have content manager posting content and project manager checking on them and aproving stuff. All 3 of them sometimes do not even know each other. Workflows can help a lot building communication. I can see drafts only helping in that direction.

@-aj- We are not talking here bout a full-functional workflow module yet, but rather about necessary buildind blocks for it, which probably should be in the core.

Edited September 3, 2014 by Ivan Gretsky

[horst]

 @-aj- We are not talking here bout a full-functional workflow module yet, but rather about necessary buildind blocks for it, which probably should be in the core.

@Ivan: as far as I understand -aj- he is aware of that and I share his opinion / suggestion on building that not in the core but building it as a paid ProFeature for enterprise customers.

[Pete]

I see it as being an addon module or modules (preferably as few as possible whilst being sensible about it of course) and yes, I think it's the sort of feature that could easily be a paid module, though I'd leave that decision to ryan.

[teppo]

I've been asked once in roughly a decade of client work if more complex workflow would be doable.. and even in that case the client ultimately decided it wasn't needed. Such things are usually for very specific use cases (online magazines etc.) or huge organisations with tons of "untrusted" content admins (which, based on my experience so far, is still quite rare, at least around here).

I can't see any reason why this couldn't be done with ProcessWire already, as a 3rd party module. If there's something that makes it impossible, perhaps we should see if that could be fixed instead. A feature that would most likely be used by very small subset of users isn't something we should force on all users in the core package.

The argument that this might attract more users is probably valid, but in my opinion it still doesn't mean that this should be a core-level addition.

[MadeMyDay]

+1 for drafts. In my opionion the "save unpublished" feature is great and for my (and my client's) needs it would be totally sufficient to have a possibility to save existing (and published) pages as a draft. Like "save and preview" or "save as draft". So the latest published version keeps being online and the new one is saved until someone hits "save and publish". Perhaps the same functionality could be achieved with using the cache. So if cache is enabled and the new version (the draft) is saved, it would be totally enough (for me) to not empty the cache until "publish" is hit. So perhaps a module which hooks into the cache management and displays an additional button "save draft" which saves the page but doesn't empty the cache. The editor can easily preview his changes because he is logged in. Guest still see the old version.

Since we are here talking about wishes: My number one wish is a (real) multisite capability. Something like contexts in MODX with customizable settings for each context (domain, templates whatsoever). The multisite module works pretty well, but it would be nice to have something like this a bit more robust with something like $context->config->host.

[SiNNuT]

This is a nice discussion about page versions/drafts, and workflow. It's interesting to see how different people assess the usefulness and potential use for this kind of stuff. In my mind page versions and a basic workflow like concrete5 has in its core, could be valuable additions to PW core, or maybe as paid modules.

The way i could see page versioning working on a page live-cycle:

• Create a page
• 'Save+keep unpublished' would create version 1 with status 'Draft', whereas,
• 'Save+publish' would create version 1 with status 'Published'
   
• Editing the page, will…
• …create a new (Draft) Version, maybe with options like 'Save as draft', 'Save draft' and 'Publish (this draft)'
   
• Publishing a draft, will…
• …change the status of both the Draft Version (it becomes “Published”)…
• …and the currently Published Version (it becomes “Previously Published”).

( The above was based on a description of the editorial cycle in a system called EPiServer. )

When you think of it a page versions are nothing more than collections of field revisions? I think page versions (or drafts if you will) would be nice, especially if this is paired with some kind of approval workflow. Of course stuff like repeaters and pagetable might complicate things but i'm sure there are ways to handle this.

[Pete]

It doesn't have to be core - an optional module makes the most sense since it's not required by most. I think some minor changes could be required in the core to make it work, but possibly not  all I know is that ryan has on occasion made changes to the core to allow for other bits of functionality but I don't expect this workflow would be a core addition.

Either way, let's not fixate on it being core or not and keep the discussion more around requirements

I'm short on time at present but I might break off all the workflow posts into a separate topic later today unless someone beats me to it (feel free mods).

[Ivan Gretsky]

That is right. This is announcements branch, not wishes. Wishes and roadmap are just around the corner.

Maybe we could break this topic apart for versions for easier navigation? "ProcessWire Dev Branch 2.5" and very soon "ProcessWire Dev Branch 2.6" and so on?

[onjegolders]

Tiny typo on the roles page:

Simply assigning the page-edit permission here does NOT give permission.