Current ProcessWire Roadmap

[ryan]

This topic has been superseded by the roadmap page.

Please see that page for the latest items on the list.

- Pete

These are a few of the items on the short-term to-do list:

• Page preview before publish (i.e. page drafts)
• Autocomplete Inputfield for use with Page Fieldtypes
• Continue posting new documentation to processwire.com
• JSON page-selection web services for use by admin modules
• Customizable page "channel" view, in addition to the sitemap view currently in ProcessWire (Admin > Pages). This will enable browsing, viewing, editing of pages outside their parent/child structure. For instance, this view can match specific properties like having the same template, modified within the last day, or anything that you can match with a selector.
• Various improvements to the FieldtypeComments module(s), including documentation!
• Simplification of the roles/permissions system. Specifically making roles assigned to templates rather than pages as the default option, and giving permissions a more clear presentation and selected defaults.
• Google Maps Fieldtype module
• Conversion of some core code into plugin modules

Some other items on the longer-term to-do list include:

• Tagscript parser that enables you to access most Page/Pages-related API capabilities via a tagscript syntax. Some ExpressionEngine users convinced me this is worthwhile, despite my preference for a pure-PHP based API. This will be developed as a module for those that want it, and it's already in the early stages. It is being patterned off of both ProcessWire 1.x and ExpressionEngine 2.x syntax. Plugin modules will also be able to define new tags.
• Built-in user form processing with admin tools to list/search/read/update/delete submissions, as well as the ability to import submissions directly to new or existing pages (with direct field mapping).
• Localization support for non-English languages.
• Strong versioning system for pages. This would also include multi-level undo and a page version comparison tool.
• Workflow functions whereby Templates can have custom statuses assigned which affect the state of the pages using them. Access to the custom statuses would be definable by Role (or User) so that any number of workflow possibilities could be supported.

These lists are not complete, and I'll be adding to them regularly.

What else do you think should be here?

[jbroussia]

I watched your video demonstrating the Page Fieldtype, very cool and all, and I also like your asmSelect plugin and your explanations for its reason to be and its usage, but I think the video also demonstrates that there is a need for some easier multi-selection control ! So many clicks to select one page, then a second one, and a third, ...

[ryan]

I watched your video demonstrating the Page Fieldtype, very cool and all, and I also like your asmSelect plugin and your explanations for its reason to be and its usage, but I think the video also demonstrates that there is a need for some easier multi-selection control ! So many clicks to select one page, then a second one, and a third, ...

I appreciate your feedback. You are right that there are a lot of clicks. Though the selection sample size was over 3,000 items in more than dozen different possible groups in the hierarchy. I could be wrong (and probably am), but I'm not aware of any other multi-selection tool that works with an unlimited sample size. In this case, the number of clicks can be reduced, but they are there for usability in feedback. Specifically, the clicks relate to:

• Navigating through hierarchy and pagination, and not showing more than a defined number of selectable elements at a time. This ensures usable scalability regardless of selectable sample size.
  
• Providing instant feedback to show where the selected item goes. This part is optional, but can be a worthwhile tradeoff.
  

One way to reduce the clicks is to not have the list collapse on each item select. I have this working already, but sitting on it for a bit. I didn't include it initially because I wanted my clients to have the instant feedback of seeing the item added to their list (i.e. click, and see where it goes). It's slower, but more clear. I also anticipated this type of selection as being one that the selectable sample size be unlimited, but the number of items actually selected being fairly small.

So while you and I may prefer to open the list once and click many items, then close the list when we are done, I was worried that would be too ambiguous for others. Also, having the list collapse on each selection means it stays consistent with the way a regular select (and asmSelect) work.

But now that I know there is someone else that wants the quicker-style of selection, I will push this forward.

[ryan]

By the way, I'm also developing a auto-completion form control for page selection. It's functional at present, but still tweaking the details. It provides the same unlimited sample size benefit, and obviously with far fewer clicks. But auto-completion is not a true multi-selection tool since you have to know something about what you'll be adding ahead of time (i.e. you need to start typing something before seeing the selectable options). Still, auto-completion is ideal in some cases, so this is on the very near-term roadmap.

[jbroussia]

By "auto-completion" do you mean some kind of filtering ? ie. I start typing something and all elements matching are displayed somewhere for selection ?

And about the multi-selection, a quicker way could be to add checkboxes to items and some button to validate the selection. Checkboxes could have multiple usage, the button having a contextual action (could allow deleting multiple items, or changing some common properties like the template associated to a page...).

[ryan]

Sorry for the delayed reply. I've been on vacation for the holidays for a few days, and just getting caught up.

By "auto-completion" do you mean some kind of filtering ? ie. I start typing something and all elements matching are displayed somewhere for selection ?

That's correct. The one  in ProcessWire uses jQuery UI's autocompletion widget, combined with a new web services module on the admin that handles the ajax-driven searches.

And about the multi-selection, a quicker way could be to add checkboxes to items and some button to validate the selection.

What it has are not unlike checkboxes, in that clicking the item causes it to reverse background/foreground color to indicate it's selected. And clicking it again, switches it back to normal, to indicate it's unselected. This way it just  stands out a little more in a large list than the regular checkbox does, but the idea is the same. Because the selectable items list stays open, there is an optional "close" button when you are done selecting items. It still adds the selected items to the list at the top (like you saw in the video), so that the selected items are summarized and can be sorted. These items are added to that list as you select them, so there is no separate validation from the form submission at present.

Checkboxes could have multiple usage, the button having a contextual action (could allow deleting multiple items, or changing some common properties like the template associated to a page...).

Removing the selected item is done from the selected list (via the trash icon), or just by clicking the selected item in the selection list. But I'm confused about what you mentioned with changing page properties (like template) from this field type. At least in the case of the sites I'm using it on, I think there may be confusion if the user is potentially changing properties of pages when selecting items for a field. But I may be misunderstanding. Can you clarify?

Thanks,

Ryan

[jbroussia]

What I meant is that, on the Page List (treeview showing the structure of the site), when you are selecting multiple items, there could be one or several additional buttons allowing to do some action on those items: delete, move, ..., for the whole selection. And why not, allow modification of common properties or settings. But that would be very tricky  For example one would select 3 pages and be able to modify the status (hidden, locked) of the 3, or the roles... or the template used, etc.

[ryan]

What I meant is that, on the Page List (treeview showing the structure of the site), when you are selecting multiple items, there could be one or several additional buttons allowing to do some action on those items: delete, move, ..., for the whole selection.

I like the potential of selecting multiple items and then being able to manipulate them as a group. For instance, like in a file system where you draw a selection around multiple files and then double click them, or move them, delete, etc.

Though I think of pages on a web site as very different from files on a filesystem, because moving (where the URL changes) or deleting pages should be discouraged. One could break a whole lot of on-or-off-site links very easily.

Still, this would be really handy in some cases, so I will be thinking about ways to implement it, perhaps combined with the tool described below…

And why not, allow modification of common properties or settings. But that would be very tricky  For example one would select 3 pages and be able to modify the status (hidden, locked) of the 3, or the roles... or the template used, etc.

Actually ProcessWire 1 had something like this, called the "find change pages tool". But it was very different in how you selected pages. The way it worked is that it presented a comprehensive search engine to you, which covered every possible field that a page could have (it would create a selector for $pages->find behind the scenes). Then it would present the results and give you the option of modifying any field on the group of found pages. That field could be internal (like template or parent) or could be any of your custom fields.

I haven't yet built this in PW2 because it's need doesn't come up so often, and when it does, it is so simple to do from an API shell script. But I know that the majority of people would not want to go create a shell script to modify pages in bulk, so this tool will make a reappearance in PW2 at some point.

Thanks,

Ryan

[nicolasbui]

As i posted in a specific message, if performances matter, then firstly switch to Nested Set model !

Great job ! I'm following you

[apeisa]

I actually haven't read this before. Nice to know the plans. I think most important things are:

• Simplification of the roles/permissions system. => Currently roles are only part in PW basics that I didn't understand right away or quite fast (I still don't understand them ). They also slow down module development in many cases, and using pw where complex user access is needed.
  
• Continue posting new documentation to processwire.com => Documentation is very important. Current documentation is clearly written and extremely helpful, but some important parts are still missing. I see here two paths: core functionalities for mod developers and advanced site builders, like $templates, $fieldgroups, UA, but also "newbie tutorials". The latter is something that community could easily help and I really believe that it could draw more people to PW
  
• Localization support for non-English languages. => Very important. I think that PW supports pretty good options to create multilingual content, but what is needed is admin languages, date formats etc. For some users though this is unimportant or completely irrelevant.
  
• Built-in user form processing with admin tools to list/search/read/update/delete submissions => Yep, very often needed and there was some nice progress in this sector recently!
  

These are very powerful features, that I really hope to see in PW, but I think that none of these should go before upper list (just a personal preference though )

• Page preview before publish (i.e. page drafts)
  
• Strong versioning system for pages. This would also include multi-level undo and a page version comparison tool.
  
• Workflow functions whereby Templates can have custom statuses assigned which affect the state of the pages using them.
  
• JSON page-selection web services for use by admin modules
  
• Customizable page "channel" view, in addition to the sitemap view currently in ProcessWire (Admin > Pages).
  
• Various improvements to the FieldtypeComments module(s), including documentation!
  

And "nice to have" list:

• Conversion of some core code into plugin modules
  
• Google Maps Fieldtype module
  
• Autocomplete Inputfield for use with Page Fieldtypes
  

Last, but not least: "not for me list" :

• Tagscript parser that enables you to access most Page/Pages-related API capabilities via a tagscript syntax.
  

[ryan]

Apeisa, thanks I think that's a great summary and order of things. I agree with everything you've said here.

JSON page-selection web services for use by admin modules

I already have this one partially done and working. I'll be happy to post it before it's done if anyone wants to play with it.

Various improvements to the FieldtypeComments module(s), including documentation!

I just posted a guide this morning in the forums. At least it's a start for the real documentation.

Thanks,

Ryan

[martinluff]

Apesia - a lot of good points there - and very important for the project as a whole to see a clear roadmap I think (and as Adamkiss mentioned elsewhere it helps focus dev resources).

My 'top' list would be pretty similar:

• docs
  
• workflow
  
• draft/versioning
  
• more complete user and roles/permissions
  
• built-in user form processing
  

I'd support all the other items although proprietary tag system would definitely be at the bottom of my list (even though my PHP is very basic). Possibly because I've run into so many issues in systems like ExpressionEngine when you start to push the tag system.

Finally, I wonder if the project would benefit from a simple thumbs-up/thumbs down system for feedback on the roadmap (like, say, http://uservoice.com/) just an idea...

[apeisa]

Just wanted to reply here just to wrap up how much processwire has progressed in little bit under 4 months:

• Simplification of the roles/permissions system. => Done in 2.1
  
• Continue posting new documentation to processwire.com => Some new docs, lot's of new posts at the forums
  
• Localization support for non-English languages. => Coming this summer in 2.2
  
• Built-in user form processing with admin tools to list/search/read/update/delete submissions => Nothing new here
  

These are very powerful features, that I really hope to see in PW, but I think that none of these should go before upper list (just a personal preference though )

• Page preview before publish (i.e. page drafts) => Done
  
• Strong versioning system for pages. This would also include multi-level undo and a page version comparison tool. => Nothing new here
  
• Workflow functions whereby Templates can have custom statuses assigned which affect the state of the pages using them. => Not done, but lot's of other new stuff for templates done
  
• JSON page-selection web services for use by admin modules  => Nothing new here
  
• Customizable page "channel" view, in addition to the sitemap view currently in ProcessWire (Admin > Pages).  => Basics done - easy to take further
  
• Various improvements to the FieldtypeComments module(s), including documentation!  => Nothing new here
  

And "nice to have" list:

• Conversion of some core code into plugin modules  => Nothing new here (?)
  
• Google Maps Fieldtype module => Qwertyee's module: http://processwire.com/talk/index.php/topic,139.0.html
  
• Autocomplete Inputfield for use with Page Fieldtypes => Nothing new here
  

Not to mention all the other modules and improvements that are not part of this list (redirects, page link abstractor, new fieldtypes etc...). And most important: more and more activity here on the forums, twitter etc! Just amazing!

[marcin]

Honestly? I'd like to help to improve PW somehow, but you guys, make such terrific things, that I feel rather embarrassed. Uber-great work.

[apeisa]

Honestly? I'd like to help to improve PW somehow, but you guys, make such terrific things, that I feel rather embarrassed. Uber-great work.

Well... It's 90% just Ryan who does all the work here, so there is definitely room for everyone's input

[ryan]

Antti, thanks for recapping the roadmap. It's interesting to look back and see what we've covered. I've not been referring back to that post very much so am glad to see it's still very relevant. I have a few more details on some of the items:

Built-in user form processing with admin tools to list/search/read/update/delete submissions => Nothing new here

The FormTemplateProcessor.module probably applies here as some progress, but it's only a start and proof-of-concept. I'm thinking we'll want the form builder to be the drive behind version 2.3 (after multi language). Though I still think this functionality will be module driven rather than core driven.

Strong versioning system for pages. This would also include multi-level undo and a page version comparison tool. => Nothing new here

I've been surprised how little this comes up. Before going open source, I had figured this capability was more important than something like multilanguage support. Now I know better. PW1 did have versioning built in and version functions do add some complexity to the system. But I'm thinking less than 30% will even use it. As a result, I'm going to target this as something that will be built as a module rather than part of the core.

Page preview before publish (i.e. page drafts) => Done

This is done, but I still want to find a way for people to preview updates to a page before publishing them. Currently there is no way to do that for an already published page (short of unpublishing it).

Workflow functions whereby Templates can have custom statuses assigned which affect the state of the pages using them. => Not done, but lot's of other new stuff for templates done

This will also be built as a module rather than as part of the core.

JSON page-selection web services for use by admin modules  => Nothing new here

Actually this is already started. It's the new ProcessPageSearch in 2.1. The plan is that it will output it's results in JSON when $config->ajax is true.

Conversion of some core code into plugin modules  => Nothing new here (?)

I think that we probably won't be pulling much more out of the core to place in modules, unless a new need comes up where it would seem beneficial to do so. Moving the Page::viewable, Page::editable, etc. functions out of the Page class and into the PagePermissions module was one of the last instances where I moved stuff out of the core and into a module. But I'm not sure that there was much benefit in doing that.

So I would change this roadmap item to be: simplifying some of the core classes to make them delegate some functions (where appropriate) to other core classes or modules. For instance, the Pages class will probably be simplified to delegate most of it's code to other more specific classes, like the Pages::save() function will probably be moved into a PagesSave class. However, this is just system architecture -- none of this will change anything about the API or how you use ProcessWire. It will just make it cleaner and more maintainable long term and provide opportunities for more hooks.

Autocomplete Inputfield for use with Page Fieldtypes => Nothing new here

Actually I built one of these that uses jQuery UI's autocomplete a few months ago. It's mostly functional, I just need to finish it. I'll be happy to send it along to anyone that wants to tinker with it.

[apeisa]

Did all the "nothing new here" items turned to "already started" state? Brilliant!

Also: good information about details on these items.

[thetuningspoon]

I currently have a client who is going to have multiple editors on the website and wants the ability to preview all edits before they go live, so I'm really seeing where a more advanced draft feature would come in handy. Since they wouldn't want articles to be removed from the site while being edited, the published/unpublished system doesn't do much for them.

Is this something on the radar?

Aside from that, a simple preview button would also be handy. There is the module that does a good job of this, but last I tried it was causing bugs with the image uploader in 2.3. I think it would be really ideal to have this as a part of the core functionality, too.

[Pete]

This topic is a little redundant in that this page on the site supersedes it: http://processwire.com/about/roadmap/ (not your fault as it's not been mentioned here!)

Your answer is most likely the first on the list for ProcessWire 2.5: "Support for maintaining separate draft and live versions of any page."

I've edited the very first post to inform people to go there to see the latest roadmap.

[thetuningspoon]

Whoops, I totally missed the last post date there! Sorry about that. Good to see that it's on the list. I'll just have to tell the client to hang in there and do the gatekeeping offline until then.