PW 2018 — Roadmap

[szabesz]

2 hours ago, mel47 said:

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

Very good point! I was in the same boat with SilverStripe. They pushed the system in the direction so that one can practically use their workflow only, major version numbered system updates were not possible because of incompatible modules, etc... Part time developers like me just could not keep up the pace with the changes introduced. In contrast, ProcessWire "just" gets new features, upgrade issues can be sorted out, and breaking API changes are virtually non-existent. You learn it once, use it "forever"  For example, I hate that when I need to re-learn M$ Windows/Word just because they completely redesigned the GUI. I'm on Mac$, anyway

Edited January 23, 2018 by szabesz
the word "breaking" was added

[tpr]

12 hours ago, szabesz said:

I hate that when I need to re-learn M$ Windows/Word just because they completely redesigned the GUI

No, they ruined it. 

[Soma]

On 19.1.2018 at 1:40 AM, Lutz Heckelmann said:

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.

We have it in use for years now on a very large site 400'000+ pages, no obvious issues so far.

[Lutz]

10 minutes ago, Soma said:

We have it in use for years now on a very large site 400'000+ pages, no obvious issues so far.

Thanks Soma, good to know. Template cache on or off? 400'000+ pages: on Apache or NGINX?

[Soma]

1 hour ago, Lutz Heckelmann said:

Thanks Soma, good to know. Template cache on or off? 400'000+ pages: on Apache or NGINX?

ProCache, Apache *hugahuga*.

[StanLindsey]

I love ProcessWire. @ryan has done such a fantastic job and I'm sure is incredibly proud.

I agree with some of the other members here that a goal of 2018 should be better community and project management in order for the community to grow and be part of the larger web development community. We do have our own way of doing things here which is fantastic, and the accessibility of ProcessWire is on point, but I fear we do lack some elements that can position us more, for lack of a better term, professionally. 

Here is my suggested list of priorities:

Long-Term Vision:  What is the long-term vision of PW? All the rest of my suggestions are coming from my long-term vision of how I wish to use PW, how I want PW to be seen by my clients and how I want PW to be viewed by other developers. But if Ryan doesn't want PW to get too big, if he doesn't want his role to become more and more of a manager and less of a sole developer role then that is fine. I can see a potential future where PW runs itself, where we have set up a structure for a team to surround Ryan, the community grows and lots of people buy Pro Modules =D 

New Website & Documentation: First impressions count, a consistent and modern site will help PW look like a real legitimate offering from the offset. Wouldn't it be fantastic if the ProcessWire website was open-source on Github - as the perfect demonstration of PW itself.

Documentation needs to be positioned as a source of truth instead of scattered across multiple blog posts / forums posts. The API CheatSheet is great but we documentation also needs to provide standards and methodology for some of the most common solutions people build with ProcessWire. The MeteorJS Docs are a fantastic example - they include a full API breakdown as well as a guide for common areas such as Application Structure, Data management, user accounts etc. https://docs.meteor.com/ 

Importantly they are open-sourced on Github, so the community can contribute. 

Project & Community Management: Continuing from the above this should not all be put on @ryan's shoulders. I think much of the website and documentation above can be handled by the community once the initial setup is there.

• Slack Channel: We're modern so let's have a modern Slack channel. 
• Team Members: Let's take some of the talented members of the PW community and give them a role if they want it. Who triages the Github issues, who can speak on behalf of the PW project that isn't Ryan?
• One Github Repo for PW: I don't understand the multiple repos for different things. Most projects don't go down that route?
• Contribution Guidelines: How to contribute to Processwire core. What are the coding standards, what issues can people currently contribute to? 
• Open up the shop: Pro Modules should be available to the public, modules like Padloper should get seen on the PW site - after some requirements are met. Developers should have an easy access to earning from supporting PW instead of just consuming PW. PW should take a tiny cut of sales as well  

Stability and Modern Practices: If PW is to be part of the larger ecosystem we have to play on some of their terms. There has been great progress with this with Namespaces, and the new Admin theme etc. We should definitely focus on fixing some of the small issues that others here have mentioned and the development cycle. We should definitely be supporting NGINX as a first party citizen. On a side note; is PW unit tested? This is a big thing for larger developers.

 

Anyway, I love ProcessWire but I feel that the community is actually quite fragmented, each of us doing our own thing in our own way in silos where the only commonality is that we consume the same framework. 

Lastly, @ryan - set up a PW Patreon. I'd happily subscribe in order to help support the development of PW technically as well as the project and community. 

[szabesz]

17 minutes ago, StanLindsey said:

Slack Channel: We're modern so let's have a modern Slack channel. 

While I generally agree to all the other points raised, I would be cautious with Slack. To tell the truth, I'm barely familiar with Slack but what I've seen so far (and that was about two years ago, so things might have changed) communication in Slack is very fragmented and hard to follow. On the contrary, our current forum has a lot of power in it and is very easy to follow. Maybe Slack can do the same but it is a question whether it is preferable or not.

Edited January 25, 2018 by szabesz
typo

[bernhard]

Great post @StanLindsey

28 minutes ago, StanLindsey said:

New Website & Documentation: First impressions count, a consistent and modern site will help PW look like a real legitimate offering from the offset. Wouldn't it be fantastic if the ProcessWire website was open-source on Github - as the perfect demonstration of PW itself.

I had exactly the same thoughts...

Regarding slack - I'm also not a fan, but it seems that many are... there was also one try to get a pw slack channel running two years ago: https://processwire.com/talk/topic/11475-processwire-slack-channel/

[StanLindsey]

To clarify - if the community at large disagrees with something (e.g. Slack) then its something to put more thought into. The primary reasoning for suggesting it is that its a common and in some ways expected in modern circles. 

It wouldn't replace the forum. So anybody who doesn't want to be part of it wouldn't have to be. Long form content is much better suited to the forum.

It would have to be supported first-party. The PW Slack Channel, "Find us on slack" on the official PW website etc. Not a sub-channel on another team's Slack group that you have to find by searching through the forum posts. Though the sentiment is definitely welcome, it's not about the existence of the thing, it's about the supporting arms around the thing. (Be it Slack, Documentation etc)

But quickly - that is one point on that list and not an overly important one. If we can instead discuss the things we really do want instead of the discussion turning towards moot points we'll get more headway in convincing the community. =D

[matjazp]

1 hour ago, StanLindsey said:

One Github Repo for PW: I don't understand the multiple repos for different things. Most projects don't go down that route?

See the explanation at https://processwire.com/blog/posts/hello-pw3/#new-github-repositories

1 hour ago, StanLindsey said:

if he doesn't want his role to become more and more of a manager and less of a sole developer role then that is fine.

If Ryan would only be the manager, he would be bored, I think. He just loves to code  

We've had this sort of conversation multiple times. I believe we all would love to help but we just don't exactly know how.

[StanLindsey]

50 minutes ago, matjazp said:

We've had this sort of conversation multiple times. I believe we all would love to help but we just don't exactly know how.

 

This is the most important thing to me. If we keep having these conversations then let us solve the root cause. How can we as a community help Ryan more? We need Ryan to help us create some frameworks and models for us to help him out. As there is a barrier of entry for us to help him. This framework can then be used for us to achieve whatever we need to (be it website, documentation, pro modules etc), with a sense of direction. 

[Noel Boss]

13 hours ago, matjazp said:

See the explanation at https://processwire.com/blog/posts/hello-pw3/#new-github-repositories

I think its time to reconsider the decision to split the repos in light of the hurdles and dissadvanatges separated repos bring for community support.

If github cant provide the features required (which are not listed) - gitlab has private repos, protected branches etc etc...

great points @StanLindsey thanks for sharing your toughts!

[gmclelland]

Community wise... I would like to see more examples of **How** people built their Processwire websites.  It would be awesome if ever so often we could some how host a Google Hangout or use https://www.crowdcast.io/ to pick volunteers from the community to showcase their Processwire websites and do a site walk through.

Here's an example of something similar https://zendev.com/2017/08/31/grids-grids-and-more-grids.html where they talk about Zurb's Foundation CSS/Javascript Framework.  They called it Foundation Open Chat https://zendev.com/category/foundation-open-chat.html   As you can see they can be embedded into a blog post as well.

Well I just saw there is a cost to using crowdcast.io.  That might not work, but maybe Google Hangouts or YouTube Live would?

I believe they do something similar with CraftCms https://straightupcraft.com/hangouts

During those sessions we could:

• ask questions about the site or Processwire?
• get to know more about a person behind the avatar?
• talk about the site's pain points and how the developer was able to work around it?
• cool module walk throughs or new module showcase?
• talk about how the site is output? does it use a template engine? Twig, Latte, Mustache, PHP, Processwire's Delay Output Method, etc..
• talk about the site's tree structure?
• talk about the site's hosting environment?

...Just some thoughts I had

[Zeka]

What I would really like to see is more expanded multilanguage support in the core as 95% of my sites is ML. Very often I need to have some pages available only in non-default languages and every time I have to reinvent the wheel with custom logic.  Almost in all modern CMSs (Statamic, Craft, October ..)  you can separately publish or unpublish pages for every language even default. There are @adrian's module and request which intended to solve this issue via a module, but as I said, I think that it should be in core. 

[StanLindsey]

 

Quote

Begin redesign and rebuild of processwire.com. When working on this, attention will shift from core updates to this project, and we hope to get started on this one soon. The modules directory and cheatsheet site are part of this as well.

 

So we're over half way through the year. How are we getting on with this @ryan? I don't see much of a discussion around it?

I think this is a really important first step to making ProcessWire part of the larger web development community and really increasing its popularity. (And sales of pro modules!).