ryangorley

2 hours ago, jploch said:

The term @ryan is referring to is called "Design by committee". 

Here is what Gemini says about it: "Design by committee" is a pejorative term used to describe a project, product, or design that has been created or approved by a large group of people (a committee), where all input is treated equally and decisions are made by consensus or compromise. The common saying, "A camel is a horse designed by committee," perfectly encapsulates the idea: the final product often lacks a clear, cohesive vision and can be over-complicated, ineffective, or even nonsensical, as it tries to incorporate every individual's idea and preference.

Would you say @jploch that what you want are expressions of functional concerns (e.g. "I'm having a hard time knowing this is expandable", "The text is hard to read", etc.) instead of design preferences (e.g. "Make the buttons bigger", "Make all the text brown")? I suggested at one point that less contrast was easier on my eyes when reading a lot of text, but maybe that was too design-by-committee-like. What would helpful feedback look like?

6 hours ago, Mikel said:

On the marketing and positioning front, it’s also important to recognize how much the market has changed. Many users today are looking for ready-made, hosted CMS solutions with out-of-the-box themes, rather than building or customizing everything themselves. When ProcessWire started, there were far fewer quality options available; now, even agencies often prefer SaaS CMSs for their convenience. So it raises the question: who is ProcessWire really for in 2025? Is it still mainly aimed at developers and agencies who need maximum flexibility, or is there a desire to broaden the target group?

3 hours ago, jploch said:

Thats a good and very important point. We where also discussing with Ryan how the CMS landscape changed and where we see PW fit in. It seems there is still a market for a CMS like PW. Take Kirby for example (they clearly took some inspiration from the PW API and they have a similar audience), it's thriving (at least here in Germany). I think that also shows how important marketing is, and that they are doing a good job with it.

I think it's important to acknowledge where ProcessWire is positioned relative to alternatives. As someone who is 67% designer and 33% developer, and an open-source enthusiast, I love ProcessWire. The API is intuitive and the documentation is excellent, making it easy to pick up and run with. I'm delighted by the attention to detail and the friendly community. Unlike Kirby, it's truly open source. I want to build every website with ProcessWire, but I don't.

I use ProcessWire when a client needs a multilingual CMS and has the budget for a custom front-end. For everything else, I reluctantly end up using WordPress with Bricks Builder and Simply Static for easier-to-build, secure sites that need a CMS, or Webstudio for easier-to-build, secure sites that don't need a CMS. If ProcessWire had a RESTful or GraphQL API that didn't require extensive work to implement, I could pair it with Webstudio and drop WordPress in many cases. But it doesn't. As much as I wish otherwise, I don't feel like I am an ideal ProcessWire user. Today, I think that user would be someone who meets most of these requirements:

• Someone who can build a site faster with code than with a visual builder
• Someone for whom multilingual support is necessary
• Someone who wants an open-source solution
• Someone who already knows PHP or wants to learn it (the "kids" are all learning JavaScript first)
• Someone with the power to choose something new or unknown (no one got fired for choosing WordPress)

A new website will help the project better reach those who fit this profile, and I'm excited about that. What we need to ask in all soberness, as well, is how many of these people exist today and will in the future. If this is not a growing audience, the product may need to evolve into something more people are seeking in the first place to restore the growth ProcessWire had in the past. 

One could do so by creating a first-class experience for those who could use ProcessWire alongside static site generators to attract a whole new audience where commercial options are prohibitively expensive and community options are limited or abandoned. Leaning into the best of a kindred JS framework like Astro could make ProcessWire a landing place for those coming from that very popular ecosystem or tempted to go there. Perhaps ProcessWire should depend upon third-party modules for some of this, but if that be the case, then let's make it easier for those creating them to commercialize their efforts or better surface those modules that are actively being maintained or at least known to be compatible with the latest release.

A new website is a huge step, and I'm excited to see it take shape. You all are so generous with your talents and have been a great blessing to me. So don't read this as some big complaint or demand. I just love the product and the community, and want ProcessWire to succeed. I hope this perspective leads to some thinking in other areas. Like I said, I just want to build every website with ProcessWire! 🙂

@jploch Thank you for this background, and these are awesome goals. Thank you as well for doing this on your own time. If you want to take a look around at the Thunderbird website we worked on a few months ago and see if any comparable 3D assets would be of value for the PW site, let me know. I don't know if it's compatible with the aesthetic, but I'd be happy to contribute the hours to create those for the cause.

3 hours ago, ryan said:

But design is always tough because it's so subjective

@ryan I would say that in most cases design seems subjective because the guiding objectives have not been well defined or communicated. Brand cohesion is a reasonable objective, and it sounds like we're going to eventually get some more visibility into that. Other objectives brought up here are worthy too. When/if @jploch @diogo have a minute, it may be helpful for us here or in a short blog post to learn how you all are prioritizing things. Design by committee doesn't work well, but if we have a rubric for providing feedback, we can provide forward momentum versus resistance. Just my $0.02.

By the way, is anyone getting a flicker on elements? I am with both Brave and Firefox. See here when I interact with a repeater matrix the Title area flicker: 

I'm personally very excited about this update. There are some great changes here. Thanks team!

One default I would propose for easier reading on bright displays is to walk back the text contrast at least 10% from black (#1a1a1a or rgba(0, 0, 0, 0.9)) and white (#e6e6e6 or rgba(255, 255, 255, 0.9)) on --text-color. Even 20% is well within the WCAG AAA contrast guidelines. Test it and see what you think. Your eyes will thank me when you're scanning a long dropdown list.

Sure, it's 10-20% less bold sauce, but the Reverse-Mullet Rule should apply to such public vs private interface priorities: Party in the Front, Business in the Back. 😉

Thanks @markus-th and @wbmnfktr. You've given me good feedback to consider.

I had an issue today with the headless WordPress site I referenced above that has me thinking about this differently. In short, the WPGraphQL plugin broke from an update and I decided to try converting what I had over to REST with Claude AI. In addition to a lengthy prompt I fed it JSON of all of the custom fields and GraphQL queries I was using on the site. That worked really well and only required minor fixes to completely rebuild what I already had.

ProcessWire has great documentation, has been around for a long time, and can export templates and fields in JSON format. I just need structured data of each page, nothing wild. I'm going to see how well the machine can generate what I need and if it seems repeatable. If anyone cares I can post how it goes.

If you're tired of the "LoOk aT WhAt i MaDe wItH Ai mOm!" posts, then I'll keep it to myself 😉

I'm sorry to resurrect this old thread, but it seems to be the most recent and authoritative discussion on this topic. I've been using an open source alternative to Webflow called Webstudio a lot more lately, especially for landing pages and microsites. It has no CMS, but can hook into any Rest/GraphQL API to serve dynamic content/pages instead. I've done that once now for a client using WordPress and the WPGraphQL plugin. I would much rather use ProcessWire as a headless backend for many reasons, not the least being its superb multilingual capabilities which I need.

Is anyone currently using any of the solutions suggested in this topic, especially with multilingual content?

It seems that some of these solutions have been abandoned. I don't even need an API per se, but just JSON formatted content, so at worst I suppose I can just write page template files to do that. But if someone has a better, tested method, I'd love to hear what you're using. Thanks!

2 hours ago, FireWire said:

@ryangorley That's interesting... My first thought is that the AJAX request is attempted but there is an error page returned by ProcessWire before the module is able to respond(?) There aren't any methods that would return an HTML page so that "<!DOCTYPE" fragment is possibly coming from an error page.

Struggling to think what could change when moving between environments would cause this to happen.

No worries! If no one else has reported this issue, perhaps it's a host specific issue. It's pretty easy to set the plugin up, so not a big deal. Thanks for the fantastic plugin!

Not a burning issue, but when I migrate a site and DB between production and dev I get this error in the console log:

fluency.bundle.js:194 [Fluency module API failure] Unexpected token '<', "<!DOCTYPE "... is not valid JSON
u @ fluency.bundle.js:194
Promise.catch
getTranslation @ fluency.bundle.js:140
(anonymous) @ fluency.bundle.js:2876

Once I uninstall and re-install Fluency it seems to work again. Just curious if you have any ideas what may be causing this issue or if there is an easy fix. If not, again, this isn't a serious problem, just an inconvenience.

Note: By migrate I mean that I am running an rsync on the template/asset directories from one to the other and doing a complete DB dump and import.

@FireWire I feel bad, because there is a note at the top of the DeepL documentation page that says Traditional isn't yet available via the API, but I guess it will be at some point. Sorry for the false alarm, and thanks for looking into this!

Hey @FireWire, thanks again for this great module. Quick question. I'm not seeing Traditional Chinese as an option. It was recently added to DeepL. Does that need to be enabled in some fashion on your end?

Thanks @wbmnfktr! Yes, these are using ProCache. I forgot to mention that one, though I worked very hard to ensure uncached pages would be fast upon first visit, which I'm very satisfied with ProcessWire they are.

Hey All,
I thought I'd jump on here and share my first 3 ProcessWire sites!

• LatticeWork (https://www.latticeworkinc.com/) - This one is live but still being actively developed in preparation for targeting an international audience (so current translations need auditing and it's not yet GDPR-compliant). The multilingual capabilities offered by ProcessWire, in contrast to WordPress, were the catalyst for starting my PW journey. The added performance that will be necessary as we deprecate some international sites and push everyone here was another decision driver for choosing PW. Obviously many thanks to @ryan and other core contributors for such an incredibly refined core product that regularly surprises me with features and functionality that I didn't know I was missing. Additional thanks go to @FireWire for the Fluency add-on, @Mike Rockett for Jumplinks, @Wanze for SEO Maestro, @teppo for Search Engine, and again Ryan for Pro Fields. These were invaluable.
• The Mart Group (https://www.martgroup.com/) - This site was my second to build with ProcessWire, though it was completed first due to its smaller size. In addition to all the prior thanks, I really appreciated RockFrontend by @bernhard while working on this one.
• Lori H. Cole (https://www.editsbylori.com/) - I probably wouldn't mention this single-page site I built as a favor, except to point out that PW is so lean and easy to work with I was able to give the client the ability to edit their own site without much server overhead or added development time.

I did the front-end development work on these, which as a designer/animator hasn't historically been an area I'm comfortable in. ProcessWire has been such a delight to use that it has re-kindled my interest in working more with code. So, in time I hope to get more creative with the front-end coding as well.

Thanks!

I'll add, perhaps for @ryan to consider, that an equally good solution would be for ProcessWire to borrow a behavior from elsewhere. In WordPress if I want to reset a slug I just clear the field and save the post. It then auto-populates that field from the post title as it does when the post is first created. In ProcessWire clearing the slug fields and saving the page just reverts the fields to their prior state. A small, but nice feature in WordPress I'd love to see in PW. :)

So, I've bumped into something worth considering.

When I added more languages to my client's site the existing pages inherited the untranslated URL slugs from the default language. So I've got to go to the Settings for each page and manually click the translate from English button for each language to pull a translated slug. That's burdensome, but it seemed to be working... until I had to start translating a bunch of blog tags, then some slugs wouldn't translate. I couldn't figure it out until I realized that Fluency must be pulling a DeepL translation from the English slug, not the English title. You'd think it wouldn't matter, but it does. Here's an example:

English > French:
AI App > Application IA
ai-app > ai-app

It turns out DeepL translates ai-app to ai-app in every language. I don't think it knows what ai-app means so it just returns it.

I don't know how commonly people will run into this problem, but I've been running into it a bit. Sometimes DeepL will return the slug unchanged, sometimes it will provide a slightly different translation than it did for the title. My suggestion would be for the slug translation prompt to use the default language page title when calling for a translation. I could see where pulling the title could create other surprises, such as when someone has the page title "Contact Us" but the slug "contact" they'll be getting longer slugs returned. Still I think that would be preferable to DeepL just silently failing. Maybe others feel differently. It's worth consideration though. 

@FireWire Got delayed on my end, but I've uploaded and tested the update. It's working great. Thank you!

20 hours ago, FireWire said:

@ryangorley fix pushed to the development branch. Let me know if that doesn't solve it!

Thanks! I'll be able to test that tomorrow afternoon.

Okay, so I'm a little late on the testing side. I love the update! I'm having one issue, which probably has nothing to do with 1.07.

The site I'm working on needs to be translated to Traditional Chinese for Taiwan (zh-tw) which isn't currently supported by DeepL and will have to be done manually. However, if I try to use Fluency when this language is added to the site it breaks with a console error:

Uncaught TypeError: Cannot read properties of null (reading 'engineLanguage') at HTMLAnchorElement.<anonymous> (fluency.bundle.js:2812:110)

Now, I presume this is because the language isn't mapped to anything in the Fluency module config. The behavior I would expect from Fluency is to just skip translations for languages not mapped, but that's not what it appears to be doing.

Is that actually the problem, and is it something easily changed?

@FireWire At first glance, this looks great. I'll pull that dev branch version down and test it out as soon as I can. Thanks!

Hopefully someone here has a good idea for the second issue. [fingers crossed]

@FireWire I'm still loving the convenience of this module, thanks! I've got a couple questions:

1. When we add new languages to a site soon we're going to have empty language fields all over. If we use "translate to all languages" again to populate these blank language fields any manual edits to existing languages will be overwritten. How easily could the "translate from English" button be added back to co-exist alongside the "translate to all languages" button, so we could just pull individual translations without altering others when needed?
2. Currently when a page is created and I translate the title, I'll have to add a space at the end of each translated title to prompt the page URL to reflect the translation. Would this be difficult to trigger automatically?

If these are non-trivial changes, let me know what it would cost to sponsor the work. Thanks!

@FireWire This plugin has saved me so much time with a site I'm building for a client. Is there anywhere I can sponsor you or a way to send a few bucks your way?

@teppo I just wanted to let you know this plugin saved my life today. Thank you for building it! I just became a sponsor :)

@elabx @7Studio Thank you both for these in-depth suggestions and explanations. This has really helped a lot!

@ngrmm Thank you also for pointing out this feature as well.

What a great a community. I really appreciate you all!

Hey all,
I'm coming from WordPress land, where blog posts, categories, tags, and publish scheduling are baked into the platform. ProcessWire is so amazing and flexible, but I'm kind of unsure about best practice for handling this. I'm migrating a site over with 100 blog posts, so I don't want to have to do it twice. This is how I expect things to work:

• Posts (pages) would be assigned to just one category (e.g. News, Guides, etc.)
• Posts could have multiple tags (e.g. iPhone Backup, Cloud Storage, etc.), and these would be shared with other posts across categories.
• An archive page would exist for each category (/blog/news/ or /blog/categories/news/) and each tag (/blog/iphone-backup/ or /blog/tags/iphone-backup/) listing all content.
• A copy writer could ideally add their own tags and see other tags have been used inside of the tag selector on a post. Categories will be predefined.
• A date can be selected for when the content becomes visible on the site, and a logged-in user can preview that content prior to that date.

Categories:

So I would imagine that the best way to handle categories would be to create sub pages of the blog page for each category and then create the posts themselves as children of the relevant categories, right? I'm mostly okay with that, though it's going to lead to longer URLs (/blog/news/this-is-a-somewhat-short-blog-post-title/). Not great for SEO, but acceptable if it's the best solution otherwise.

Tags:

This is the one I'm lost on. I haven't played with it yet, but I know there is a tag input field. I don't know if it is aware of existing tags so we don't get too much duplication (e.g. iphone, iPhone, Iphone, i-phone, etc.). I know I can figure that out, but if someone knows already and can share it would save me some time. The big question is how do I go about automatically generating archives of all the blog posts that share each tag? Tags need to be shared across categories, so the sub page method wouldn't work as a fallback. Someone must have figured this out, but I can't find anything documented.

Publish Date:

So I get that I can add a date field and build some logic into the queries to not show pages if today is prior to that value. I imagine I would use the $user ->isLoggedin() method to display the page content if today is prior to that date value as well. I don't love doing things this way because my sitemap (generated by SEOMaestro) is going to list these pages, and they are going to get indexed by crawlers as empty. I'm wondering if there is some better method for handling this functionality.

--

Thanks in advance for the advice here!