ryangorley

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?

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.

@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!

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. :)