PW 2018 — Roadmap

[ryan]

In this post, we take a look at all that was covered in 2017, and our roadmap for 2018, which includes plans for the year ahead.

https://processwire.com/blog/posts/processwire-2018-roadmap/

[The Frayed Ends of Sanity]

This all looks interesting as usual. Thanks

Can someone explain what the following means for PW? Preferably with an example of how it would be used?

Quote

A front-end JS $pages API still remains a priority, though likely as something outside of the core. Though if there is strong interest, this may very well end up in the core too.

 

[Tom.]

I don't think this has ever been specified. I always thought it was a REST API for using things like React. 

[Robin S]

It sounds like one of the factors that determines which roadmap items get attention first is the level of interest within the community (makes sense).

But it would be good to have a more accurate and transparent gauge of the interest in each roadmap item. A simple solution would be to have an official Roadmap sub-forum with a topic for each roadmap item (separate from the Wishlist sub-forum). The community could then indicate their interest in each item by "liking" it, and give feedback or ideas about implementation in topic replies.

My vote for most desirable roadmap item: Add support for custom properties in file/image fields.

[Peter Knight]

That's an amazing list of 2017's features. Seeing them in a single place makes you appreciate how lucky we and our clients are. Thanks for another incredible year of updates.

Quote

We'd also like to hear from you all about what you'd like to see in 2018 for ProcessWire, and in the years ahead. 

I imagine everyone's wish list is different. This is what I'd like to see natively in PW. I know some of these are already available as Modules so no offence if you're reading this and have already put tons of work into creating something similar.

Processwire Multi-Admin 
A Processwire dashboard which allows me to monitor multiple installs across different servers. This dashboard would list my installs, version number, and display available upgrades (Module and Core) and allow me to update above from central place. It might show me logged in user(s), uptime etc.

Media Manager
A built in MM which acts as a single place to manage all uploads. Using the MM you can find, list and edit any uploaded file/image. and its versions. Add tags, crop, delete, rename, copy, bulk upload etc Furthermore the MM should work with user permissions so a MM for me might list different assets than an editor etc

Importantly, the look of the MM would be consistent with what's already in place and the new UI Kit theme.

SEO
A native SEO Module that is maintained and updated as modern SEO evolves.

Image Cropping
Pre-set image crops and a way to define and manage them.

 

That's it :-/

[Juergen]

SEO and image cropping is also what I find very useful.

In addition to image manipulations it would be great to add a feature that makes the scaling of images to FIT/FILL bounding boxes possible. Take a look at http://a32.me/2012/06/scale-images-to-fit-fill-bounding-box-in-php-using-gd/ for a detailed example.

This is useful if you have images with different proportions fitting in a box (fe. logos of different partners, product images).

Best regards

[gmclelland]

FYI... There is also a discussion around focal point image cropping https://github.com/processwire/processwire-requests/issues/150 if anyone is interested.

[titanium]

On 13.1.2018 at 11:02 AM, Peter Knight said:

SEO
A native SEO Module that is maintained and updated as modern SEO evolves.

There is a SEO module already. I guess it's not maintained anymore, but it can be a good base for extensions. What do you miss?

Personally, I don't think a SEO module belongs to the core (if it's that what you have meant by "native"), because the core should keep it's clean and generic character. Keep in mind that ProcessWire is not just used for websites, and even a lot of websites don't need that much SEO.

[Robin S]

5 hours ago, Juergen said:

In addition to image manipulations it would be great to add a feature that makes the scaling of images to FIT/FILL bounding boxes possible. Take a look at http://a32.me/2012/06/scale-images-to-fit-fill-bounding-box-in-php-using-gd/ for a detailed example.

Filling the bounding box is the standard behaviour for the size() method.

$image->size(300, 200);

For fit, I think it's a not a good idea to add background colour to the canvas. Better to use maxSize(), or size() with cropping set to false, and then center the image within the bounding box with CSS.

But if you want to add a background colour you can do this with the canvas() method of Page Image Manipulator.

[bernhard]

On 12.1.2018 at 11:39 PM, Robin S said:

But it would be good to have a more accurate and transparent gauge of the interest in each roadmap item. A simple solution would be to have an official Roadmap sub-forum with a topic for each roadmap item (separate from the Wishlist sub-forum). The community could then indicate their interest in each item by "liking" it, and give feedback or ideas about implementation in topic replies.

totally agree! right now it sometimes seems that the interest is measured by "who shouts loudest"... but we had several examples where users didn't show their interest because the feature has been on the roadmap for a while so nobody said anything about it and waited for a surprise in the next blogpost.

14 hours ago, gmclelland said:

FYI... There is also a discussion around focal point image cropping https://github.com/processwire/processwire-requests/issues/150 if anyone is interested.

just if it was requested this is great example of what robin is talking about. informations about upcoming features are spread over the forum (wishlist) and github...

so i want to support robins request and maybe extend it a little bit towards "better community management". we had one occasion where @ryan implemented something that was already available as a module (image tagging). don't get me wrong, of course i prefer solid solutions built into the core over 3rd party modules (i was voting for the predefined-crop-in-the-core-feature for a long time), but i would love to see a little more discussion and community involvment here.

i can imagine that this can eat up a lot of time if done wrong - but i think it can also save time if done right. for example the community could do some research (like in the github link above), bring in ideas or point ryan to already existing solutions like it was the case with image tagging.

finally i want to thank everybody contributing to this project and helping me out in the forum. i had a great 2017 and it would not have been possible without this awesome product and community! happy and successful 2018 to everybody 

[adrian]

1 hour ago, bernhard said:

finally i want to thank everybody contributing to this project and helping me out in the forum. i had a great 2017 and it would not have been possible without this awesome product and community!

Thanks to you Bernhard - you're an integral part of this community too - the stats tell us one of the top 5 for the year

[Noel Boss]

On 1/13/2018 at 11:02 AM, Peter Knight said:

Media Manager
A built in MM which acts as a single place to manage all uploads. Using the MM you can find, list and edit any uploaded file/image. and its versions. Add tags, crop, delete, rename, copy, bulk upload etc Furthermore the MM should work with user permissions so a MM for me might list different assets than an editor etc

Importantly, the look of the MM would be consistent with what's already in place and the new UI Kit theme.

Would be amazing and one of the only missing parts from my point of view.

[pwired]

Roadmap: I want a separate channel in the forum where everybody can upload graphics, banners, animations and video clips to promote processwire.

[bernhard]

@noelboss just posted a comment in this thread and the thread is just one of many examples of people looking for solutions of a proper staging/production strategy. we have some modules that try to close this gap, but imho this is an important part of a professional workflow and therefore should be part of the core. don't know how that could be implemented exactly, but at least it would be great to have a thought-out strategy and maybe some kind of standard/best practise guide of how to keep staging/production in sync, be safe while editing, integrate GIT in this process etc.

while other features are nice to have for me, this is really one thing that makes me feel totally unprofessional and is a huge pain. i don't think that the options we have so far are as good as they could be. for example if i had to push a fix to a live system, i wished it would be possible to:

• pull the latest version from live to dev with one click (excluding a predefined list of files / db tables)
• work on that dev version locally (having all files on the local computer makes searching all files a lot easier)
• push the fix to git
• push the fix to production

some parts of this workflow can be done with the migrations module, some with the quite new duplicator module, some could be implemented via githooks, but, hey... we are talking about ProcessWire and where PW really shines is making our lives as devs easier and in this special case i feel that this is not true  maybe i'm just too inexperienced in this topic and there are proper solutions out there, but following the forum over the last years i didn't see a solution that felt "processwire-awesome". maybe a blog-post covering this topic could be a first step.

and maybe i'm totally alone with this opinion... a feature request-voting system could also help a lot here

 

[pub]

4 hours ago, adrian said:

the stats tell us one of the top 5 for the year

that was the tracy-boost

[Noel Boss]

17 hours ago, bernhard said:

just one of many examples of people looking for solutions of a proper staging/production strategy.

Ah true, forgot to mention it, this was also one of the only things I identified as a drawback while working on my first PW project.

While not perfect, there is a solution for WP that could help as an inspiration: https://deliciousbrains.com/wp-migrate-db-pro/

We are using Gitlab with Hooks to automatically deploy files to the staging and live systems on the corresponding branches and wp-migrate-db-pro for DB syncs as well as the .htaccess method to reference files not found on staging and development environments.

If it would work reliably, this module could be an easy solution to migrate templates: 

 

 

[szabesz]

I would like to add something else to this already great discussion, and this is about the rate of new features and changes introduced in ProcessWire. While the last few year's new features are impressive, they keep introducing so many minor issues that – while they are truly minor – they have already accumulated to the point where I cannot see how each of them will get sorted out in the future. Leaving these issues behind in the dust will make ProcessWire less robust in the long run.

Do not get me wrong, I do no think ProcessWire is in any sort of trouble just yet but recently I stopped updating to new dev versions fearing that I might break a site.

The last stable is v3.0.62 from May 5, 2017. I would love to see a feature freeze so that a new stable and somewhat tested version can be released.

[Peter Knight]

I completely forgot about the dev/staging/live workflow too. +1 for that

22 hours ago, noelboss said:

While not perfect, there is a solution for WP that could help as an inspiration: https://deliciousbrains.com/wp-migrate-db-pro/

That's a great source of inspiration. I particularly like the detail and options within that Addon such as

1.  Pre-saved migration profiles
2. Push / Pull and Export options 
3. Push / Pull site URL and secret keys etc
etc

I found a few more such as Craft Migration Manager and MODX Cloud have a very easy site inject service although it doesn't give you many options re. which tables, fields etc to import.

Just a small point about GIT. I know many of you guys are very comfortable interacting with the CLI and GitHub. Some of us here wouldn't be as strong in that regard so it'd be great to see integration with GIT but not so great if the Module depended on it etc. 

[bernhard]

[offtopic, sorry, please comment here in case of questions/interest]

19 minutes ago, Peter Knight said:

Just a small point about GIT. I know many of you guys are very comfortable interacting with the CLI and GitHub. Some of us here wouldn't be as strong in that regard so it'd be great to see integration with GIT but not so great if the Module depended on it etc. 

Agree it should not be a dependency, but regarding git I can really recommend gitlab.com + vscode - no cli at all, all free and really nice and easy UI:

[matjazp]

2 hours ago, szabesz said:

While the last few year's new features are impressive, they keep introducing so many minor issues that – while they are truly minor – they have already accumulated to the point where I cannot see how each of them will get sorted out if the future. Leaving these issues behind in the dust will make ProcessWire less robust in the long run.

I agree. While I do like new features, I like even more fixing the old issues and making PW stable. Those minor things and issues that are open for days/months/years make me/us creating and maintaining workarounds, like extra css/js files, using "small" modules, putting hooks in ready.php and you never know when and how these mods will affect the next release. When some time ago new repositories for PW was made (issues/requests) I hoped this will make PW issues solving more consistent (with the help of PW members, I think lostkobrakai and isellsoap), but it looks like nothing much has changed. As Ryan said: "The focus often depends on what resources are available in any given week, and what the most immediate needs are for current projects and clients." I understand that but still...

2 hours ago, szabesz said:

I would love to see a feature freeze so that a new stable and somewhat tested version can be released.

I would love that too. Let's stop requesting new features so Ryan could focus on making the stable release.

[szabesz]

1 hour ago, matjazp said:

Those minor things and issues that are open for days/months/years make me/us creating and maintaining workarounds, like extra css/js files, using "small" modules, putting hooks in ready.php and you never know when and how these mods will affect the next release.

Making future website upgrades more error prone and time consuming, I agree.

1 hour ago, matjazp said:

When some time ago new repositories for PW was made (issues/requests) I hoped this will make PW issues solving more consistent (with the help of PW members, I think lostkobrakai and isellsoap), but it looks like nothing much has changed.

Yes, we should get more organized somehow.

[bernhard]

22 minutes ago, szabesz said:

1 hour ago, matjazp said:

Those minor things and issues that are open for days/months/years make me/us creating and maintaining workarounds, like extra css/js files, using "small" modules, putting hooks in ready.php and you never know when and how these mods will affect the next release.

Making future website upgrades more error prone and time consuming, I agree.

I don't have this feeling. One of the things I like most about PW is that I don't really have to care about updates. But I agree that it would be better to have less new features pushed out every week and have a little more conversation upfront to make the result as good as possible.

 

30 minutes ago, szabesz said:

1 hour ago, matjazp said:

When some time ago new repositories for PW was made (issues/requests) I hoped this will make PW issues solving more consistent (with the help of PW members, I think lostkobrakai and isellsoap), but it looks like nothing much has changed.

Yes, we should get more organized somehow.

yep, my vote for better community managment here

On 15.1.2018 at 12:13 PM, bernhard said:

so i want to support robins request and maybe extend it a little bit towards "better community management"

I'd be happy to help in this regard as much as I can.

[Lutz]

A lot of interesting ideas here. Nevertheless, I'm a bit nervous, because I hoped to see a focus on critical features missing when building larger websites, with full-fledged editorial teams (larger teams, with copy editors and editors, designers, ...). 

Think about editorial flows: Of course there are already helpful parts available, e.g. ProDraft. But it would be a big help to have page versioning in core, and collision detection!

And think about teams with specialists for different work areas: Photographers and photo editors, who upload files into a central media repository and categorize them, so that editors have a logical place to search for article images, headers. To find an unique image language, sometimes with repeated use of some of the images. To publish in this way is a difficult process. Not something that could easily get replaced by AI. It's a special kind of work of human beeings, who like to be creative and want to get technical support in a way they understand and they need. 

They want to have access to large galleries that they can filter. To look at their selections in a preview, that shows teasers next to the others in the area concerned. To get an impression how it works, how images works with headlines, and teasers works beside their neighbors. And publishers like to see reasons to have confidence in the scalability and further development of key features for their workflows, their cms. Therefore it seems to be important to have a, in this regard fundamental, set of key features for larger publishing teams available, in a quality and with support, that creates trust in pw as a solid and future-proof platform for larger projects.

I understand the difficulties and I know some of the arguments regarding versioning, or for one-page-one-image workarounds (against a central media management). But I'm not convinced by these arguments.

More in detail, regarding the media management question. I think the maybe best way to achieve a pw kind of a media solution wouldn't be a central, fixed media library, but to build something like a central media archive out of pages – but with multiple images per page, selectable from an image field, like images of other pages are selectable from ckeditor fields. And yes, I know that there are modules that try to offer such a solution. So maybe it's not too difficult to come to a solution in technical terms. However, it makes a difference to see such a module and such a workflow as a well known and documented way to build a reliable media management, to know it as a part of trying to establish pw as a solid alternative for building larger websites with larger teams.

Similarly regarding scalability questions. We have $config->pagefileExtendedPaths. But is that thoroughly enough tested that we can say we can definitely count on it? Does template cache work with it or not? (I wasn't able to test it out by myself.) Ryan wrote 2014: "Will have to revisit that
with a similar solution to the files at some point in the future". (https://github.com/ryancramerdesign/ProcessWire/issues/432) If we could clarify this question, that would be very good. I mean, a good thing for the ProcessWire 2018 Roadmap.

And last but not least: official NGINX support.

To be clear: I'm not concerned to criticize any contribution to the roadmap, or have anything to complain about pw. On the contrary, I hope it will be possible to advance pw. But I think it would be a good idea to focus on critical areas regarding the use of pw for larger projects, for larger editorial teams. Decisions regarding a publishing platform depends on features we can offer, but not in a simple way, that we just could show this or that functionality. More important, I think, is to give a perspective that creates confidence in serious steps to build reliable tools, to enable reliable workflows for demanding tasks of teams, i.e. to establish pw, even for more complex teams of editors and for larger websites.

This is a lesson to learn from the development of Craft. Of course, it doesn't make much sense to compare the projects, and to compare them is not my point. Success in one way or another not always depends on resources. Sometimes it's more a question of clarity and organization – sometimes success depends primarily on focusing on key issues. Although the basic requirements are very different, in many cases pw is a valuable solution right now. But it would be good to find the critical questions that the project should face, and to leave less important ones aside.

EDIT: A short note regarding the NGINX question, apart from posts in the forum there's an older, very simple attempt on howtoforge, https://www.howtoforge.com/running-processwire-on-nginx-lemp-on-debian-wheezy-ubuntu-13.04. And an article about installing pw 3.0.62 on Ubuntu 17.04/17.10 with NGINX, https://websiteforstudents.com/install-processwire-on-ubuntu-17-04-17-10-with-nginx-mariadb-and-php-support/.

Just as an example what a useful approach could look like: https://github.com/nystudio107/nginx-craft
Would be great to achieve something like that for pw, with special consideration of ProCache.

Edited January 22, 2018 by Lutz Heckelmann
Additional note

[Noel Boss]

On 1/17/2018 at 1:18 PM, szabesz said:

On 1/17/2018 at 12:00 PM, matjazp said:

When some time ago new repositories for PW was made (issues/requests) I hoped this will make PW issues solving more consistent (with the help of PW members, I think lostkobrakai and isellsoap), but it looks like nothing much has changed.

Yes, we should get more organized somehow.

I agree with the above comments. As a fairly new member of the community I get the impression, that the projects grows more rapidly that the current structures can handle.

@ryan - I love the work you (and some in the community) have done so far! I would love to see PW succeed in becoming even easier to use, more feature rich and still beeing stable. I belief with the continued success of the project, more involvement of the community is needed – and therefore an increased focus on coordination from someone (does not have to be you if it's not what you like to do.).

One example where I think the current setup hinders this are the separate GIT repositories for issues, code and feature request. I don't know the reasons for this, there might be some good ones I don't know of yet. But from a community standpoint, it makes things complicated and opaque. A central GIT repository would allow the community to participate much better by providing code to PW in the correct context, without much effort using pull requests. Advantages of one central repository would by:

• Exposure:
  • More bugs get reported because its easier
  • Bugs have better visibility, increasing the reach of developers who can potentially fix it
• Engagement:
  • Issues can be discussed side by side, draft solutions can be pushed
  • Using pull-requests the community can contribute bugfixes and features in a known way
  • Using milestones, the community can help implement roadmap features
• Clarity & Code Quality:
  • Bugs, discussions and fixed code live side by side, making things easier to understand
  • Code review make code more stable
• Marketing:
  • Because there will be more activity on one repository, the project looks more healthy and active for someone judging PW based on this criteria (I myself check issues and activity on open source projects beforehand – if I find no reported bugs and fixes this is a big warning sign)

This is just one thing, there are probably other areas where we as a community could support the development of PW better. Im thinking roadmap with milestones etc, semantic versioning, etc. But I suggest to change evrything at once, rome wasn't built in a day  Or as our pastor said, same same but a little bit better…

Most important, it would be great to have an ongoing discussion about this.

On 1/17/2018 at 1:50 PM, bernhard said:

I'd be happy to help in this regard as much as I can.

I'm in as well  As one of only two 80% developers for a church with 60+ locations, I know the need of creating a flourishing community of volunteers firsthand. To take an example: If I can increase my productivity by 20% my project can grow faster by 20%. But if I invest time to onboard 2 others to help me do my work – the project can grow at 200%! I call for many Ryans  We need more of the good people on this earth!

But for a community to be able to get involved, there needs to be a some (hard) groundwork like simple tools, easy access, clear contribution guidelines, clear roadmaps... A healthy community needs a sense of ownership and unity there needs to be fun etc… 

I belief that the whole PW universe is amazing, its a great project, @ryan is a great leader, many members are very skilled, polite and very loyal. If we can get more of us to help, the whole ecosystem would greatly flourish – there is tremendous potential in unleashing the full power of the community by letting it get involved easier.  

[mel47]

Hi,

I normally don't express myself on those kind of discussions, but as a newcomer, and a also as non-professionnal developper, I want to emphases about simplicity of PW. I really liked the fact I was able to construct something even with my basic knowledge of PHP, and the system could sustain more complicated things, with my knowledge growing. IMHO, it should stay like this, open to everyone. In the previous CMS I used, I started like this, simple and understandable, but with years become so focused to developers than it was impossible to follow developments if you don't used it on day-to-day basis (maybe because me and other people like me didn't feel included and never participated to roadmaps discussion!!). I understand those having different needs than me, but I don't know if it's possible to find a way to activate/install more advanced features without impacting a simple core.

I agree with latest posters, small issues should be fixed. Furthermore, I still wondering why really small useful things are not included in the core (and already existent). Just 2 examples: I put on forum my wish to have a button to save+add new field (as already existing in pages).  @Robin S created this module in couple of hours. Second example : PW upgrade : who don't use that? Why it's not included in core? There is many small things like this.

Thanks everyone for your work AND your answers to my naïve questions.

Mel

 

 

[matjazp]

38 minutes ago, mel47 said:

I agree with latest posters, small issues should be fixed. Furthermore, I still wondering why really small useful things are not included in the core (and already existent). Just 2 examples: I put on forum my wish to have a button to save+add new field (as already existing in pages).

I agree. Those small modules, included in the core modules, would not bring any overhead, on contrary, it would reduce the total number of hooking and autoload modules.

41 minutes ago, mel47 said:

Second example : PW upgrade : who don't use that? Why it's not included in core?

I don't know, Ryan is the only one who could provide the answer. There is feature request for this https://github.com/processwire/processwire-requests/issues/136. In this post (Roadmap for 2016) https://processwire.com/blog/posts/happy-new-year-heres-a-roadmap-for-processwire-in-2016/ Ryan said: "One of the goals with 3.x is to make the core smaller rather than larger. Consistent with this, we'll be evaluating all the currently bundled core modules and determining which ones no longer belong in the core." Maybe this is the reason?