Weekly update – 11 July 2024

[ryan]

@bernhard

Quote

So if you ask me it would be ideal if PW had a shop for commercial modules where all you have to do is add a github link to a private github repo and PW does the rest. Which is invoicing, taxes, generating license keys, offering download links etc. 

That sounds good to me. Probably out of scope relative to our resources in the short term, but longer term this sounds like the ideal. 

Quote

I know we've "lost" people just because they looked at the github repo and saw the last commit on the main branch was over a year ago and they thought the project is dead. 

This is one of many reasons why I like to get a new main/master version out, but it's probably not often enough. Maybe one way to keep the main branch fresh for folks looking at the date you pointed to is if we maintained a changelog type of file that covered all the versions, including the dev branch versions. This changelog file would exist on both branches and get merged to the main/master branch every time the version number was increased, regardless of branch. 

Also a good point about the README links. That makes sense that those links should move closer to the top. Maybe at the top it should also mention that there are new dev branch versions at least every month. 

Quote

I also checked the download page on the website:

Good ideas.

Quote

I don't know if growing the userbase of PW is a goal of ryan at all or should be. 

Growing the user base is good for everyone. Good for us and the community, and good for those new users who get something great they didn't know about before. 

Quote

And while I can remember that a lot has improved it's still not a great website at first sight, to be honest.

I think I mentioned "overhaul of this website" in the message that started this thread. We are ready for a redesign after 7 years no doubt. Ideally I'd like to have a pro design it, someone like @diogo or one of the other great professional designers in the community, like those you mentioned. I've thought a redesign could be both of the website and the admin, and that perhaps they even use the same design/theme. I have some rough ideas about the design concept but I'm not the right one to design it.  

Quote

All a first time visitor will see is an more or less default UIkit theme which looks outdated to be honest. 

It's definitely not a default Uikit theme by any stretch, but if that's the impression you get, then understood. 

One thing that looks dated is the computer on the homepage, it's still my 2017 iMac that I use everyday, so my computer is a bit outdated too! But until we have a new design in place, I've thought I should just remove that computer and leave the text. 

Quote

Maybe github issues of gold sponsors could be addressed with priority or such. I don't know. 

Something like this might be good at least for instances where someone wants priority attention to one thing or another that might not otherwise get priority. I focus largely on issues that are easily reproducible and affect many people. If an issue only appears naturally in very rare instances and is a simple matter to work around, or if it's difficult to reproduce (requiring a lot of set up or combinations of factors), then I try to delay those until time is more abundant. I can easily lose days of work trying to identify and fix obscure issues that won't help many people. The reality is I love going down these rabbit holes, fixing things is actually quite fun, but I have to be careful and pick-and-choose or I'll lose valuable time with little to show for it. 

Quote

Instead it should show a huge warning like this:

I love it!

Quote

What if we dropped the skyscraper profile and instead built a new modules directory which can serve as a new showcase?

I do wonder if the modules showcase is relatable enough to people that don't already know PW, and thus may not know what modules are. Might also be confusing in the admin side, where there's also a Modules tab, and folks might get mixed up about what is what. But I like the idea of having a different demo site, regardless of what data it is showcasing. 

What about if we linked to off-site demos? Your demo for RockFrontend is fantastic and I like how it actually lets them edit everything and resets it every hour (is this really secure?). But I imagine you and others in the community could also build a great ProcessWire demo that we could link to. The win-win of it would be that we'd be sending you traffic and you could promote your tools in the demo as well. The same demo page on the ProcessWire site could link to the demo for RockFrontend, PAGEGRID, and others. Basically, a compilation of PW demos, rather than just one. I could also update the Skyscrapers profile and make that one of them, but even an updated one should probably be near the end of the list of demos at this point. 

Quote

What about a section where we showcase "ProcessWire as XXX Alternative in 2024"

Always a good idea. We kind of do that already in the About section, but it needs a content refresh. Also, having the year in there is a good idea since I think that's what people are searching for, and thus attracts search traffic.

Quote

At the moment basically anybody doing business with PW has to "sell" processwire as the correct tool on his own. Not everybody is good at marketing though, so it would be great if that was done by experts. For example we could have professional guides why pw is the right tool for job x or y on the official website.

Good points. The "sell" part of it isn't really in my bloodstream, so as you say, it's something where we'd need experts. I was looking through your website the other day and actually think you do a great job of communicating and thereby selling your products and services. Your skills here also come across in your recommendations, thank you for all of the good ideas. 

 

[bernhard]

45 minutes ago, ryan said:

This is one of many reasons why I like to get a new main/master version out, but it's probably not often enough.

I don't think it's bad to have less frequent master versions, it just needs to be clear that PW is VERY actively developed. Maybe I'm not the right person to ask, though, because I'm always on dev ? 

But in terms of marketing I think alone such a schedule could be worth gold: https://ubuntu.com/about/release-cycle

This alone says a lot:

• They have a plan
• They care about their product and their customers
• When choosing a recent version (24.04) I'll likely be fine for the next 10+ years until 2036
• They still support 14.04 which is more than 10 years old, which says a lot
• I as a customer know what to expect

A lot of that is true for PW as well, just nobody knows.

In some parts we are not there yet (I think part of that has already been mentioned as versioning chaos or similar). So maybe instead of semantic versioning we could introduce PW 24.04 LTS and PW 24.10, 25.04, 25.10, PW 26.04 LTS... I think having such a release cycle could help in many ways, like working on clear roadmaps, prioritising issues or features and it could also help developers in what to tackle and what to just wait for until it is built into the core or a pro module.

Also, having a 10 year LTS would be an incredible strong marketing signal! And PW - as we all know, but many don't - has always been like this, which is outstanding.

--- I have to leave unfortunately ---

1 hour ago, ryan said:

I do wonder if the modules showcase is relatable enough to people that don't already know PW, and thus may not know what modules are. Might also be confusing in the admin side, where there's also a Modules tab, and folks might get mixed up about what is what. But I like the idea of having a different demo site, regardless of what data it is showcasing. 

So what if we used the PW developer directory for this instead? I think this would be a win-win again. First of all we showcase our developers instead of skyscrapers ? We show that PW is used by many developers around the world and when done correctly this could also be such a thing that I meant when saying "help devs to make money". For example if that profile looked really good and showcased the skills of that developer, he/she could use that profile to show his/her skills and credibility to customers and hopefully sell more, make more money, contribute more to PW, etc.

Every PW developer should feel like a hero, not a stranger using something that nobody else uses (again please don't take me word by word). We could maybe show the forum post and like count, show badges, show site of the week awards, etc. This could serve as a kind of gamification on one hand but could serve a very serious aspect on the other hand: Help the dev grow as a dev, grow as a business, grow as a person.

It could show statements of other developers, like "what others say about me". So if a potential client doesn't know a developer the developer could share his PW profile and it might help in getting the job.

1 hour ago, ryan said:

Good points. The "sell" part of it isn't really in my bloodstream, so as you say, it's something where we'd need experts. I was looking through your website the other day and actually think you do a great job of communicating and thereby selling your products and services. Your skills here also come across in your recommendations, thank you for all of the good ideas. 

Thank you very much. Glad if something was helpful!

Now I really need to run. Marketing experts, the stage is yours ? 

[d'Hinnisdaël]

Quote

One thing that looks dated is the computer on the homepage, it's still my 2017 iMac that I use everyday, so my computer is a bit outdated too! But until we have a new design in place, I've thought I should just remove that computer and leave the text. 

The animation on the homepage is a bit hard too read at its current size. Getting rid of the iMac and the IDE background and showing just the Safari windows should allow things to get a bit larger. Apart from that, the design of the site is fine in my opinion. Not sure if a complete overhaul is a great investment of time here.

Quote

I do wonder if the modules showcase is relatable enough to people that don't already know PW, and thus may not know what modules are.

I agree that the content of the demo site should be unrelated to the ProcessWire ecosystem to make it relatable and understandable by newcomers. Skycrapers were and are pretty great here. Birds would also be fun ? 

Quote

What about if we linked to off-site demos? The same demo page on the ProcessWire site could link to the demo for RockFrontend, PAGEGRID, and others.

If we create and link to demo sites, I'd be wary of using (too many) commercial modules. Otherwise we're creating the impression that people need to buy a bunch of paid modules to create nice websites with ProcessWire. We should definitely strive for a commercial module showcase, but mixing that with demos sends the wrong signal in my opinion.

[monollonom]

Actually having a demo per (first party) site profile would be a good showcase of how these can be good starting points while showing how versatile PW can be, e.g. with the (great) invoice profile.

[szabesz]

The issue with any kind of demo site catalog is that someone needs to make sure there are no outdated profiles and new ones should also be added frequently (preferably).

It would be possible to have the profile import its catalog data upon install, so new installs would receive up-to-date data, but who would be the one to keep that data up-to-date in the fist place?

I also have a similar idea and that might not be visually as attractive as a catalog of nice looking websites, but would be much more useful for us and also for a newcomer: https://processwire.recipes/ but with some trained (on PW) AI tool added, like:

• https://huggingface.co/blog/how-to-train
• https://www.google.com/search?q=how+to+train+my+own+language+model

And community users could maintain its database somehow...

[AndZyk]

@ryan 

On topic of the website:

There is a YouTube video embedded on the documentation for multi-language fields, which is set to be private since a while:
https://processwire.com/docs/multi-language-support/multi-language-fields/

Also the ProcessWire Developer Directory has still the old design and is now broken for years:
https://directory.processwire.com/

?

Regards, Andreas 

[ottogal]

As a non professional webdesigner (pure amateur...) I'd like to add to the discussion of versioning.
I experienced that a potential "client" I wanted to convince of PW got the impression that in 3.0.xxx the quickly increasing values of xxx would indicate a continously need of fixing lots of bugs. (At the end he changed his opinion.)
But also for me it's not comprehensible that we didn't have steps to 3.1 or even 3.2 back already, since there have been some notable achievements in the meantime.

[d'Hinnisdaël]

1 hour ago, ottogal said:

But also for me it's not comprehensible that we didn't have steps to 3.1 or even 3.2 back already, since there have been some notable achievements in the meantime.

At the risk of repeating myself: semantic versioning would be a small but extremely helpful step toward a more seamless upgrade experience. Having an unusual versioning scheme would be perfectly fine if there was a public changelog available. Currently, upgrading is a crapshoot — you can't tell from the version number if it's a fix release or a feature release, and there's no changelog to help figure it out. Going source-diving is an option, but not feasible for every single update. One could stick with the master version, but the latest master was released 11 months ago and it's common to aim for quarterly security updates, so we're back to the dev branch.

[bernhard]

1 hour ago, d'Hinnisdaël said:

At the risk of repeating myself: semantic versioning would be a small but extremely helpful step toward a more seamless upgrade experience.

I'm not totally against that. I'm using semver for all my modules as well. But it also has downsides:

1. Complexity: SemVer can be complex to implement correctly, especially for large projects with many dependencies.
2. Subjective interpretation: Determining what constitutes a "breaking change" can be subjective, leading to inconsistent version bumps.
3. Rapid major version increases: Frequent breaking changes can lead to quickly incrementing major versions, potentially causing version number inflation.
4. Dependency hell: In ecosystems with many interdependent packages, strict adherence to SemVer can still lead to compatibility issues.
5. Limited expressiveness: SemVer doesn't capture all types of changes, such as performance improvements or security fixes.
6. User expectations: Users may expect significant new features with every version increment, which isn't always the case.
7. Backward compatibility pressure: Developers may avoid making necessary breaking changes to prevent major version bumps.
8. Learning curve: New team members or contributors may need time to understand and correctly apply SemVer principles.

I've experienced some of them on my own.

1 hour ago, d'Hinnisdaël said:

Having an unusual versioning scheme would be perfectly fine if there was a public changelog available. Currently, upgrading is a crapshoot — you can't tell from the version number if it's a fix release or a feature release, and there's no changelog to help figure it out.

Personally I can't remember of a single situation where upgrading PW was a big problem. Maybe I had some minor issues, but I can't even remember a single one. Everything that is pushed to the core is listed in the commit log, so you can easily have a look there and check if upgrading is a problem for your specific instance or not. I think that's our responsibility as developers.

I understand that it's tempting to go with SemVer, but I'm quite sure that once we have it there will be people complaining that they did an upgrade from PW 4.xx to 4.yy and there was something wrong...

For the upgrade from 2.x to 3.x Ryan even added an upgrade guide: https://processwire.com/docs/start/install/upgrade/from-2.x/

So I'm not sure if your suggested switch to SemVer would improve things a lot, at least I don't understand it from what you wrote.

Not saying that release cycles like in my ubuntu screenshot above would solve all problems, but I like the strong message that it sends out and I don't see such a message in PW 4.x, 4.y, 4.z ? 

Having regular releases could imho help in keeping focus. We (Ryan) could for example state that for the next LTS release the focus lies on improving the admin theme. In the next LTS the focus could lie on building a module ecosystem. In the next LTS ... you get it.

Not sure if mixing LTS versions with stuff that is not code but project-related would be a good idea, but I wanted to throw in that idea.

Maybe it would help to split the roadmap/ideas/requests into two parts, one for PW itself and one for the project/community around it.

[szabesz]

ProcessWire do not have to strictly follow SemVer, there are alternatives, for example: https://github.com/romversioning/romver

Or better yet, we could come up with our own, tailored to both ProcessWire and its modules.

The issue is that currently there is not much transparency, except for those who keep an eye on Ryan's weekly messages and his longer blog posts from time to time. I think versioning could be improved.

[JayGee]

I would like to second the votes for greater developer tooling. Things like:

• Being able to re-use the same field in a template.
• Being able to more easily and natively version control template/field definitions.
  • Perhaps definition of template fields from inside the template code itself or page class?
• Perhaps better support of raw html in template views vs. php files - maybe through an enhanced JS api for field content, or using data-attributes directly in html. This would smooth development pathways from front-end design/dev to backend with less reliance on local/dev php servers and more 'headless' functionality. (Obviously not a major hangup, but just a slight modernisation).

[d'Hinnisdaël]

20 hours ago, bernhard said:

I'm not totally against that. I'm using semver for all my modules as well. But it also has downsides:

1. Complexity: SemVer can be complex to implement correctly, especially for large projects with many dependencies.
2. Subjective interpretation: Determining what constitutes a "breaking change" can be subjective, leading to inconsistent version bumps.
3. Rapid major version increases: Frequent breaking changes can lead to quickly incrementing major versions, potentially causing version number inflation.
4. Dependency hell: In ecosystems with many interdependent packages, strict adherence to SemVer can still lead to compatibility issues.
5. Limited expressiveness: SemVer doesn't capture all types of changes, such as performance improvements or security fixes.
6. User expectations: Users may expect significant new features with every version increment, which isn't always the case.
7. Backward compatibility pressure: Developers may avoid making necessary breaking changes to prevent major version bumps.
8. Learning curve: New team members or contributors may need time to understand and correctly apply SemVer principles.

Asking an AI about the downsides of any versioning scheme will produce a list like that, not sure if that's helpful ?

Quote

Everything that is pushed to the core is listed in the commit log, so you can easily have a look there and check if upgrading is a problem for your specific instance or not. I think that's our responsibility as developers.

The word "easily" is doing a lot of work here — I don't think it's easy to read through every commit in a three-month span when doing quarterly updates of a ProcessWire instance. And while an experienced ProcessWire dev might be able to spot an issue, we can't expect newcomers to read the source code to determine if an upgrade is safe or not. If we want to grow the community, a public changelog shouldn't be controversial in 2024.

Quote

Having regular releases could imho help in keeping focus. We (Ryan) could for example state that for the next LTS release the focus lies on improving the admin theme. In the next LTS the focus could lie on building a module ecosystem. In the next LTS ... you get it.

The marketing aspect of an LTS versioning scheme is a good point. The danger is of course the "L" in LTS — not sure if there's much appetite to keep supporting releases other than the current one, unless it's sponsored or tied to a paid support tier. Not calling it LTS but e.g. "focus release" would of course get rid of that problem. The idea is nice in any case — communicating the current development focus.

[Christophe]

Dev ProcessWire could just have a second firstname, Rolling.

What about a(n) appointment, booking, scheduling (, calendar) system as a new site profile?
Edit: Perhaps integrated as a module(s).

Edited August 3 by Christophe

[poljpocket]

I think ProcessWire has a well-estabilshed versioning plan: Ryan is increasing the version every few commits whenever some notable new feature was introduced. And the master version then just follows suit. I think a set release schedule with fixed time intervals is a very bad idea. I have been working with WordPress in the past and they have been notoriously bad at using their fixed minor release schedule. Sometimes a version introduced very important and big features and other times, there was barely anything new but both were minor releases just because the schedule said so.

I have only been in the ProcessWire game for almost three years and thus have started out around where version 200 was released. At that time, I didn't look at GitHub too much though. I didn't notice the "slow releases" at all and was mostly influcenced by the forum and the website. For me, they did a good job. As many before me have mentioned, community activity is very important especially for new potential users (and even more to the target audience: fellow developers). This could also be reflected in more activity on the master branch. Finding a good solution might not be the easiest endeavour though.

On 8/2/2024 at 2:00 PM, d'Hinnisdaël said:

The marketing aspect of an LTS versioning scheme is a good point. The danger is of course the "L" in LTS — not sure if there's much appetite to keep supporting releases other than the current one, unless it's sponsored or tied to a paid support tier. Not calling it LTS but e.g. "focus release" would of course get rid of that problem. The idea is nice in any case — communicating the current development focus.

Has there ever been a situation where old versions needed to be patched for some bugs or security vulnerabilities? I haven't seen one yet. I think this mostly stems from the slow master releases which only ever get done when high stability has been reached. So for me, every master release is a "LTS" version, which is a big strength of ProcessWire: I have no reason to ever update a PW website I did years ago. As long as it doesn't get outdated because of external influences (PHP EOL comes to mind).

On 7/31/2024 at 5:34 PM, bernhard said:

In some parts we are not there yet (I think part of that has already been mentioned as versioning chaos or similar). So maybe instead of semantic versioning we could introduce PW 24.04 LTS and PW 24.10, 25.04, 25.10, PW 26.04 LTS... I think having such a release cycle could help in many ways, like working on clear roadmaps, prioritising issues or features and it could also help developers in what to tackle and what to just wait for until it is built into the core or a pro module.

I think using time-based releases like Ubuntu or Windows don't make much sense for ProcessWire. Years give a feeling of outdatedness. This directly contradicts ProcessWire's strengths: It does away with the stability and ease of upkeep arguments. How do you explain to a client that PW 2016.3 is still completely fine in 2024 and doesn't need any updates whatsoever? With operating systems, you want a sense of outdatedness simply because there is much more incentive to update to never versions, e.g. for hardware compatibility or platform support.

Why not stick with semver with a few adjustments? One idea is to keep the patch part of the current versions as sort of like a build number which would primarily be used on the dev branch to indicate new features and fixes. And then every master version gets a minor version bump which corresponds to a dev version (indirectly that is). This would then allow for security fix updates down the road. Not that this would be needed much :).

[wbmnfktr]

From my perspective this is mostly spot-on @poljpocket.

Yet there are a few things I'd like to add here:

• those of us that are active in the forum, read the weekly posts from Ryan, read weekly.pw from Teppo and follow every last bit... ProcessWire is evolving each day, each week, each month, all the time. YET... the last commit to master was 9-10 months ago, which is a century or two ago in the fast-living webdev-world - mostly due to the JS-sphere. I know a lot of people that look very close at this metric, but unfortunatelly on the wrong branch in this case.
   
• I'd love to see (and I personally keep it this way) the master branch as something like an LTS, while dev is more like a stable-rolling-release of some kind. I'd probably even use an unstable branch in some projects, even though there is no branch for it. BUT this isn't about naming, but MARKETING. And the last push on master is really bad marketing for ProcessWire right now. That's all I am saying. It doesn't look good. This needs to be changed. I don't care how, but it needs to be fixed. Fast!
   
• I don't care if we use SEMVER, ROMVER, WHATeVER, or any other way of versioning (besides the one from Ubuntu, which is really a bad look in the long run and introduces a lot of stress as there has to be a release no matter what at a specific date). All I need to know is if there are breaking changes or new requirements, like min. PHP 8.x and similar. I won't see (as in recognize) this in the version number and wouldn't even think about breaking changes the moment a ProcessWire 4.2 pops up in my upgrade module. Yeah, sorry... I just click UPGRADE as most of the users out there.
  
  Maybe the upgrading process/module needs a few upgrades, tricks, and markers to show and tell breaking changes, changed requirements, and what not. Sure more work for module developers but probably not really. Modules already have all these details like requirements. I'm not that deep into developing but as a user... that would be nice!
   

One more thing...

In this thread a lot of things were mentioned but mostly like "I'd like to have this feature and this, and that, and ..." which is fine. I'd support most of that. But  I'd like to know and ask:

• Where do we want to see ProcessWire in 5-10 years?
• What can I do to support ProcessWire/Ryan more?

 

[wbmnfktr]

On 8/1/2024 at 8:38 AM, szabesz said:

I also have a similar idea and that might not be visually as attractive as a catalog of nice looking websites, but would be much more useful for us and also for a newcomer: https://processwire.recipes/ but with some trained (on PW) AI tool added

Well... processwire.recipes uses Astro as of right now, therefore not a great example but...
I can offer processwire.pw as a demo platform and resource.
Yet I'm open to move processwire.recipes over to ProcessWire and the community.
That's why I re-booted it. It's for the community - not me.

Btw - I was finally able to get the old domain / @marcus:

As I mentioned Astro here... they have an awesome way to communicate their progress and they move pretty fast.
Their versioning and communication, community talk and support on social media is on point.

Maybe those points should be added to the ProcessWire 20XX agenda as well.

• more community work*
• more visibility in social media*
• more activity in social media*
  • * yes, that's most of the time on us and not on @ryan
• more communication and posts on processwire.com/blog
  • every weekly forum post should be a blog post, and the blog should be the leading source (my opinion) - right now it's in the forum, but... a new thread in the forum with a link to the blog post would work for me and would be even better for everyone. As mentioned before: it's about marketing, therefore the blog should be the leading source. (Change my mind!)
  • blog posts should be posted on: X/Twitter, Facebook, Reddit, Discord ... whereever we have an official home or community - and even in non-official homes.
  • final solutions from the forums which involve PHP/API code should/could be posted to processwire.recipes (ping me to add that recipe if you like!)
    • for ProcessWire, modules, hooks, hacks, ready.php, whatever
    • it's easy to add a recipe

 

Thoughts about Demos and Profiles

• each and every profile should be super close to the user, the user's needs and therefore a longliving and understable profile and concept.
• Examples should be timeless, therefore no need to update them once in a while:
  • Skyscrapers ?
  • American Diner Restaurant
  • Classic Movies Collection
  • Grand Mom's Recipes
  • Antique Shop Inventory
  • Billboard Charts History
    • these examples alone would support everything we all ever faced and built - I guess. (Apps not included, but as starters)
  • all these examples would build a solid foundation for all kinds of websites and projects we face nowadays (still apps and custom things not included)

 

I repeat myself here but I can offer processwire.pw as a demo platform for that, all we need is long-term

• Hosting
• SSL
• CI/CD deployment and/or
• someone that maintains those installations

[EyeDentify]

Hello There @ryan just wanted to add my concerns here.

I am not an "advanced" developer, i just develop sites or conduct experiments on my own personal website thats been running PW for a very long time now.

That being said, i have read through this tread and i have become a little worried that PW would be going away from it´s root that made me many years ago fall in love with it.

I am concerned that many of the more advanced users of the CMS want´s to take it to a more complicated place instead of keeping PW simple for us beginners to pick up and use wich is why i love it.

As a laymans dev i can actually understand most of the API and what i can use it for.

Ryan have made some posts in this tread that makes me feel calmer that the core simplicity is not going to go away.

I also feel that many of the more advanced devs are missing the point of PW simplicty and why not everything should be in the core.
There is modules for a reason,, want something special?, then create a module.

Reasons PW appeal to me:
1. It´s API made sense from the start, logicaly and was adopted fast by my Authistic brain.
2. It´s does not interfere with how i want to render my website.
3. It´s has a great admin backend that should not confuse anyone.
4. PW is not WP.

Thank you all.
 

[Ivan Gretsky]

I am with you @EyeDentify when you praise PW's simplicity and easiness to start to get around. But PW is also great being a powerful framework. Ryan always managed to balance things perfectly. New cool things like custom page classes never disturbed ones that didn't need them. So I am sure we can easily move forward making PW more suitable for larger projects, multi dev on the same project, more best practice compliance without sacrificing simplicity for the newbies.

[nurkka]

Here are some additional feature ideas:

- The feature to define the TinyMCE-configuration of all your TinyMCE fields in a "parent"-field is so great - how about if we could have that with more fieldtypes? In my sites, I have tons of fields, which change from time to time, and as one can't use fields more than once on a template, I have e.g. image_single_1, image_single_2, image_single_3. It would be great to change all those e.g. image fields at once, by just changing a "parent field". Please tell me, if I missed that feature, if it already exists ?

- Nearly all my sites have to be MultiLanguage sites, and therefore, a multilanguage image field would be great. I know Language-alternate fields, but a "real" field would be really great. The most complex project, I am working on, has currently 10 languages. When creating and maintaining all the needed fields, this is a lot of work, which could be much easier with a multilanguage image field.

- As I am still working with (nested) RepeaterMatrix and Repeater fields, keeping track of fields which are really used or not used is a complicated, as simple fields often are displayed as "in use" on some pages, while those pages are not "real" pages, but system pages of repeaters. I hope you know what I mean. The feature suggestion in this case is to extend the display of fields on the fields admin page so the relations between the fields are somehow more comprehensible.

- Also, the fields list get's confusing, if you have some hundred fields – the UI could be refined somehow, to make the fields list easier to work with.*

* I'll try to start a thread about naming fields, because I tend to change my naming scheme with every project, because I try to find the perfect one - which I did't find yet. Perhaps you are willing to share your naming schemes. I am sure someone already invented the perfect scheme ?

[bernhard]

21 hours ago, nurkka said:

- The feature to define the TinyMCE-configuration of all your TinyMCE fields in a "parent"-field is so great - how about if we could have that with more fieldtypes? In my sites, I have tons of fields, which change from time to time, and as one can't use fields more than once on a template, I have e.g. image_single_1, image_single_2, image_single_3. It would be great to change all those e.g. image fields at once, by just changing a "parent field". Please tell me, if I missed that feature, if it already exists ?

These things are so easy to do with RockMigrations:

<?php
// site/migrate.php

$defaults = [
  'type' => 'image',
  'maxFiles' => 1,
  'descriptionRows' => 1,
  'extensions' => 'jpg jpeg gif png svg',
  'maxSize' => 3, // max 3 megapixels
  'icon' => 'picture-o',
  'gridMode' => 'grid', // grid, left, list
];
$rm->createField('your_image_field1', $defaults);
$rm->createField('your_image_field2', $defaults);
$rm->createField('your_image_field3', $defaults);

You can then set custom labels for your fields or you can even set custom properties either in migrate.php overriding the defaults or via GUI as template context override.

PS: If the fields already exist you CAN use ->setFieldData() instead, but ->createField() will work as well.

PPS: If you need to change a setting just change the setting in the defaults, save the file and refresh your web broser!

[poljpocket]

7 hours ago, nurkka said:

- The feature to define the TinyMCE-configuration of all your TinyMCE fields in a "parent"-field is so great - how about if we could have that with more fieldtypes? In my sites, I have tons of fields, which change from time to time, and as one can't use fields more than once on a template, I have e.g. image_single_1, image_single_2, image_single_3. It would be great to change all those e.g. image fields at once, by just changing a "parent field". Please tell me, if I missed that feature, if it already exists ?

- Nearly all my sites have to be MultiLanguage sites, and therefore, a multilanguage image field would be great. I know Language-alternate fields, but a "real" field would be really great. The most complex project, I am working on, has currently 10 languages. When creating and maintaining all the needed fields, this is a lot of work, which could be much easier with a multilanguage image field.

Me too. You can solve this (from a technical point of view at least) by using language-alternate fields. Combine that with @bernhard's great suggestion to sync settings between your language fields and you should be all set. The only thing you're not getting from that is the cool tabs system LanguageTabs provides.

7 hours ago, nurkka said:

- As I am still working with (nested) RepeaterMatrix and Repeater fields, keeping track of fields which are really used or not used is a complicated, as simple fields often are displayed as "in use" on some pages, while those pages are not "real" pages, but system pages of repeaters. I hope you know what I mean. The feature suggestion in this case is to extend the display of fields on the fields admin page so the relations between the fields are somehow more comprehensible.

- Also, the fields list get's confusing, if you have some hundred fields – the UI could be refined somehow, to make the fields list easier to work with.*

* I'll try to start a thread about naming fields, because I tend to change my naming scheme with every project, because I try to find the perfect one - which I did't find yet. Perhaps you are willing to share your naming schemes. I am sure someone already invented the perfect scheme ?

I am always extensively tagging both templates and fields. With the tags, you can even have some of them be collapsed by default. This retains all the overview I need.

[Andy]

Hi @wbmnfktr

On 8/4/2024 at 2:35 AM, wbmnfktr said:

Thoughts about Demos and Profiles

• each and every profile should be super close to the user, the user's needs and therefore a longliving and understable profile and concept.
• Examples should be timeless, therefore no need to update them once in a while:
  • Skyscrapers ?
  • American Diner Restaurant
  • Classic Movies Collection
  • Grand Mom's Recipes
  • Antique Shop Inventory
  • Billboard Charts History
    • these examples alone would support everything we all ever faced and built - I guess. (Apps not included, but as starters)
  • all these examples would build a solid foundation for all kinds of websites and projects we face nowadays (still apps and custom things not included)

I think generic layouts should cover more functionality and showcase features.

Skyscrapers - A perfect illustration of map integration. Add to this the skyscrapers of Hong Kong (554 skyscrapers) and add Chinese language in the frontend. I think the multi-language functionality in PW is the best of any CMS. I had a client who wanted a website to have the following languages: English, Greek, Russian, Chinese. The only problem was finding a font that has all the lettering. I love ProcessWire's multilingual tools.

The Shop - is a simple store layout for simple products. No taxes or shipping, just an order cart and that's it. It's a seed on which a big tree can grow later.

Admin dashboard in backend - This functionality is available in many CMSs. A typical layout will show beginners how easy it is to customize the backend to suit their needs.

Making an appointment - is a booking system for anything. This is a pretty common task that happens when you need to book a hotel, buy airline tickets from make an appointment with a dentist. This kind of layout will be useful to many people.

I proceed from the premise that typical PW installations should show the functionality and flexibility of this system. Of course, ProcessWire's capabilities are much broader and constantly evolving. I have tried to point out only the key needs.

What else can be illustrated? For example, flexible customization of access levels and user roles.

 

 

[heldercervantes]

On 7/31/2024 at 11:45 AM, bernhard said:

At least @heldercervantes showed his interest in that in 2017.

Still interested. I agree the site doesn't do justice to the product. Wordpress is looking pretty good these days, and the only other alternative I've seen deserving of notice, CraftCMS, is also looking pretty good.

I think our site is directed too much at the developer audience, and I often found myself having to convince my clients that this is a better option than Wordpress or whatever platform they have in mind. And the site doesn't help much at that.

If you guys want to consider a redesign, I'll gladly join that effort.

[Jan Romero]

1 hour ago, heldercervantes said:

I think our site is directed too much at the developer audience

I don’t think that’s a bad thing per se, but I agree the big PHPStorm background could probably be replaced by just the slideshow of PW admin screenshots that currently plays awkwardly on top of it. Perhaps with one or two code screenshots intermixed.

In general though, maybe I’m just old, but the site doesn’t look outdated to me at all? At least the frontpage looks as fresh as ever to me. Welcoming, professional, you name it. Certainly no worse than the examples mentioned? Wordpress has a trendy serif typeface which I get is part of their printing press shtick, but I honestly find kind of offputting for what it is (also the footer is grade A pure unadulturated organic cringe and all their images are blocked by Firefox’s default tracking protection).

Structurally I think the ProcessWire site could use some improving, especially these “hub” pages like https://processwire.com/docs/, especially especially if they link to the next identical looking hub page (eg. https://processwire.com/docs/start/). Someone mentioned earlier that it’s a shame a lot of great nuggets and frankly vital info can practically only be found in blog posts. I know I’ve searched for specific blog entries I knew existed plenty of times, wondering how someone who hasn’t kept up with PW for over a decade would find out about stuff like custom user parents, for example. It would be great to have a more official tutorial section for these things which the blog posts would then link to. The current tutorial section only has 10 tuts, most of which, including the "More Tutorials" link, are secretly external.

[BrendonKoz]

I've been wanting to review the 5 pages of responses and summarize the findings, but what I will say before (if?) I get to that:

There seems to be three primary audiences that PW is catering to, or that it can potentially cater to:

1. Developers (ease of development, API, headless, documentation, module development/sales, etc)
2. Clients (security, continuously developed, version stability, availability of developers)
3. Consumers: A developer and client all in one (all the ways in which it competes, and how it's different)

It may not be evidently clear what the project is primarily aimed at catering to, and perhaps that needs to be clarified, whether directly by Ryan in terms of what he is interested/able in supporting, or by the community's desire (as Ryan seems amicable to our opinions on steering it). That may also help guide any potential website redesigns. I think this is an important question to really consider and have answered. Although it can be done, it's really hard to properly target all three of the above, all at once.