Leaderboard

ProcessWire has always communicated well to developers and they typically aren't the ones that need to be convinced. We always connect with the developers. But the decision makers are more often the clients, designers, marketers, etc. They are the ones that we hope to increase visibility to. Several updates to the new site this week, various minor optimizations and improvements. The biggest additions were made in the API reference, which now covers a lot more methods and has some navigation improvements as well.

I think we need both. Clients usually ask what CMS the developer uses and more often then not visits the website. So the website should also help the developer to convince the client.

We are still targeting developers. But we are trying to be more accessible. Many of us where not trained developers when we started to use PW. And programming can feel intimidating. For example Diogo and I where designers and then became developers when we discovered PW. The great thing about PW is that it’s relatively easy for beginners to get started. Even with little coding experience. I think it’s not a bad idea to make PW approachable for more users.

I think both developers and clients should be the target audience and I cannot see why it would not be possible to target both. Anyway, in my opinion, the new design "targets typographers". To me, it looks like solution to a school assignment for students studying typography. BTW, I found an error in the following href:

@Jonathan Lahijani thank you very much! A lot of what you wrote resonates with me. Did you also try/consider daisyui? The have 35k stars on Github, a MIT license and so far I didn't find anything that I would miss coming from UIkit.

@bernhard Within the Tailwind ecosystem, my goal was to find the "framework" that had the best JavaScript components (the typical things like accordions, tabs, etc.). I started with Tailwind UI but that was geared for headless, however behind the scenes in their demos they had a hidden Alpine.js based solution. That was hacky but I used it for a little bit. Then Alpine.js itself had their premium components and since the two pair well, I went with that for a while but it didn't feel right in the same way that UIkit does. Then I found Preline and played with that for a while, but a couple years ago it was good but not as good as Flowbite. So I stuck with Flowbite for the last 2 years. A couple months ago I re-visited Preline and they've made some incredible progress, so much so that I feel it's "ahead" of Flowbite. Then a month or two ago, the folks at Tailwind finally released non-headless / vanilla JS components officially for Tailwind UI, which I haven't experimented with yet but I'll probably switch to that if it makes sense (which I'm sure it will): https://tailwindcss.com/blog/vanilla-js-support-for-tailwind-plus Also, I've been thinking about eventually switching back to vanilla CSS at some point because of how much progress it's made in the last 15 years. I stopped writing vanilla CSS when Bootstrap 2 came out and every since then I've gone from one framework to another (Bootstrap 2 -> Foundation -> Bootstrap 3 -> Uikit2 -> Uikit3 -> Tailwind). I love UIkit but I feel it's antiquated now and not taking advantage of all the new cool features of CSS. I also came to not like being softly "jailed" in their way of doing things. Also I like the idea of not using a build-step so vanilla CSS is probably what I'll settle on when I'm ready.

I understand the design decisions behind this change, but please consider restoring the showcase section on the home page (even a simplified one). Regardless of the target audience, in my opinion, this is one of the most important sections. Words are important, but for a new visitor, they're just words (any other solution will try to describe its advantages). Visitors need examples to illustrate these words, and in my opinion, the admin panel screenshots at the top aren't sufficient. The showcase provides first rough examples of what can be built and what the user can achieve before they decide to invest their time — for example, downloading and installing ProcessWire. They can also encourage users to dive deeper, reading more, looking for features, etc. Just my 2 cents.

I understand the logic here, but in my opinion that's wrong target audience. How will less technical user build website with processwire as there is no themes and "plug-and-play" plugins? If im a marketeer, or content-editor, why and how would i choose processwire, because there is a text "flexible, stable..."? Or because processwire has great API, and technically built really well, how would i know if im non-technical, how would i evaluate the CMS, based on a big headline? If you are really so confident about target audience, at least there is a need for some really good demo. I believe we need more developers pushing clients to use processwire, not vise versa.

@Pete - I've just pushed a lot of critical fixes, so just in case you have already started testing, please grab the latest version. I knew there was a good reason I hadn't looked into doing this before :)

Thank you for your feedback! And thanks to @ryan for the technical implementation. I am currently on vacation and am only now able to respond here. I understand that it takes some time to get used to change, especially when you are attached to something. And there will always be different evaluations and opinions about design. However, it is important to me to say that there are reasons for our design decisions and that they were not made arbitrarily. Due to time constraints, I will only be able to address a few points here. The overarching theme of the design is “friendly flexibility.” All design decisions were made to emphasize this theme and find a consistent visual language. With the new design, we want to appear less technical and also include user groups other than developers, such as designers, marketers, and editors/content creators. At the same time, we want to differentiate ourselves from other comparable CMS products and highlight PW's uniqueness. The morphing animations are intended to communicate the versatility and flexibility of PW and engage users. For example, we used many adjectives on the old site (flexible, stable, secure, open, free, powerful, etc.) and our idea was to communicate this directly in the first headline. The font (“Apfel Grotesk”) we used has many curves and a friendly character, which is especially noticeable when used in larger headlines. The colors used have been part of PW's branding from the beginning, so we thought it would be good to continue using them. By mixing these colors, we want to communicate versatility again and move away from the rather technical and dominant blue of the old site. We also greatly reduced the amount of text per scroll on the homepage, because we felt the old site was lacking visual hierarchy and felt to crowded. We have a much more guided flow on the homepage now that makes users actually read the text and it's easier to scan the content. We have also improved the visibility of features and modules and adjusted the navigation structure. I can provide more details on this when I have more time. I hope it adds some context to our decisions.

Hey @Pete - if you want to try it out: https://github.com/adrianbj/TracyDebugger/tree/namespaced I am not ready to commit to the master branch yet because there were a lot of changes required and I have a feeling I still might have missed some things - most likely core PHP things like DirectoryIterator etc that need to be prepended by \ to get them called from the global namespace.

@markus-th In my view there's no reason to be confused, there's a disagreement on the strategy, that's all. Your position doesn't confuse me, I understand it perfectly, I just don't necessarily agree that it's the best path. Also notice that I carefully worded that sentence to convey that this is only one of the aspects that we discussed. It doesn't mean that it was the most important one and it doesn't mean we discarded other targets. We still think the site will convince developers to go deeper and discover PW. What we did, in that aspect, is not much different from what greatly successful tools aimed at developers are doing. From the top of my mind, see Next, Astro and Svelte

Thanks you for your opinions and suggestions, they are very welcome! We can always count on this community for engagement 👍 One aspect that we discussed, and that I don't think Ryan mentioned, is that Jan and I had several clients express concern about the tool after visiting the previous website. PW has some recognition among developers, but zero recognition among non technical potential clients, who we need to accept PW as our CMS suggestion. That's also one of the reasons of having "CMS" and not "CMS/CMF" front and center. Design decisions will never please everyone, we were aware of that and decided to go bold anyway. Hopefully it will prove to have been the right decision 🙂 That could be a fun animation to make 😆 Seriously, though, I think we discussed this at a certain point. Not sure why we dropped it, maybe because being headless in PW is a possibility and not a feature, while all the other things on the homepage are inherent to PW. The GraphQL plugin could certainly be on the modules area in the homepage, though.

Hey @Pete - I maintain four different Tracy core versions which are all included and used based on the version of PHP available. I have also made a real effort to ensure PHP 7 compatibility (maybe even 5 - not sure). A Tracy upgrade is basically instantaneous on all my servers/installs so I've never thought of the compiling process as an issue. Adding a namespace is probably more of a big deal with so many panels and reliance on the Tracy core itself - maybe just a matter of lots of backspaces to start loading things from the global namespace. The one other module I namespaced was AdminActions and it was a real challenge but that was mostly due to trying to support installed custom user actions whether they were namespaced or not. Still, it put me off namespacing others. I'll try to find some time to see what's involved sometime soon.

@adrian To be fair both are very nice sites. I see so many sites, and I like to look through the lens of how memorable it is. Like whether there's anything strongly unique or surprising that makes me want to click further inside, and hooks into my memory so that I can recall it later. That's what I'm missing from the Contentful site, even if it is nicely designed. As a visual learner, I'm drawn in by bold visuals and anything that makes a site different from any others. That's also what I'd like to communicate about PW, as something different from the Contentfuls, Wordpressers, and Drupals of the world. On the PW site, the large headline is unexpected/surprising, and whether one likes it or not, it's memorable, bold and stands out from the crowd. Likewise with the abstract animations, they communicate the concepts (to me and I'm sure others) in a way that text just doesn't. There's plenty to read for the book learners too. So whether one subjectively likes some of these things or not, I think it will prove to be memorable and engaging, and good for gaining new users.

To clarify and gently push back on this, prefers-reduced-motion isn't just for people who may have a preference for no animation. Personally I'm fine with animations. It's an accessibility feature that allows people who may be affected by animations (e.g. vestibular disorders) to send a signal to websites from their OS or browser. It's good practice to check for that and respect it, when possible, especially if they're non-critical animations.

Congrats on the launch @ryan Would it be possible to get some kind of webhook that I can call and send data to? I have everything automated for all my modules and I really don't want to log into the modules directory to push all my updates manually 😞 It would probably be ok to add all the readmes once, but still all the version numbers and the "last updated" indicator would be outdated as all my paid modules are private git repos. And I put a lot of effort into all my pro modules, so it would be nice if that could be visible somehow in the modules directory. See RockCalendar as an example: https://www.baumrock.com/en/releases/rockcalendar/ Ideally we'd have a github workflow that anybody can add to his/her project that automatically sends new data to the modules directory on every new release. I can build that workflow if you want and all you'd have to do is to add it to the github repo (like this example from RockShell) so that we all can use it in our CI automations and then add an url hook to processwire.com that reads the data from the webhook and updates the modules directory entry.

If you're looking for a JS library that pairs well with Tailwind, might I recommend Preline, which I just found on Hacker News: https://preline.co/ Another option includes Flowbite, but at the time of this writing, Preline's JS goes a bit further and has more components and more options (such as offcanvas, mega menu): https://flowbite.com/ There's also Alpine Components if you're into Alpine, however it's commercial: https://alpinejs.dev/components I like Alpine.js, but the "locality of behavior" approach it takes for these common components is not my style. I do use it elsewhere however. - Lastly, there's Headless UI, but that probably won't fit with a typical ProcessWire frontend unless you are using React or Vue: https://headlessui.com/ I wish Headless UI had a Alpine.js version, but the author of Tailwind ultimately scrapped the idea (it was mentioned in a Tweet thread somewhere). This would have been my go-to approach, assuming it was comprehensive enough. But there's many options as stated above.

This works for me: $pages->addHookAfter("ProcessPageEdit::buildFormContent", function($event) { if($event->object->getPage()->id !== 1016) return; $wrapper = $event->return; if(!$wrapper->has('body')) return; $wrapper->body->collapsed = Inputfield::collapsedHidden; }); I have included a check for the ID of the page being edited. So in this case it will only hide the "body" field on a page with ID 1016. Hopefully you can modify that for your needs. BTW, I just put that code in my site/init.php file - no need for a module for something so simple.