wbmnfktr

In terms of ProcessWire: Probably absolute nothing - maybe clearing cache and cookies. In terms of Matomo: I'm not that sure if there is a path somewhere or anything that needs to be fixed.

Just to get this right... does your folder structure within your hosting look like this? If so... that's NOT how you do it. Each domain and (almost) all subdomains should have their very own folder. A bit more like this: There should be a tool or config where you can map domains and sub-domains to their very own folder. Otherwise you will almost always have issues. Your ProcessWire on www.mydomain.tld isn't able to change behaviour of matomo.mydomain.tld UNLESS you mix it up like in the first screenshot.

I'd say the "How to do it" is your personal preference. Using breakpoints, JavaScript a mix of both, whatever fit's your needs and tools. The way more important part or question is or should be: Which parts of the navigation need to be visible at what point and at which position? I say that because on a personal blog you can do whatever you want while noone really cares. They know they are on a blog and they most likely will find what they are looking for. On the other hand there are lots of patterns (already burned into the users brains) people look for. A shop is totally different in terms of navigaton than a wiki. A restaurant has totally different focus than an insurance company. Look up all the big online shops. In terms of navigation, search inputs, browsing... they are almost exactly the same. Either due to those patterns or because they all use the same framework/components (for example: Shopify). Sure there are fancy ones but those only speak to a small audience that's looking for a specific item or experience and don't just browse to spend money. Compare websites from big players and brands to your clients. People know clicking the top-left logo brings them back to the homepage, while the top-right ☰ means there is menu when clicking. Each niche and type of website has it's very own patterns, behaviours and things people look for. Maybe that's a better thing to focus on. And don't forget to have fallbacks for those without javascript, using screen-readers or keyboard-driven navigation. Accessibility is a huge part here. (I'm guilty on this one but I'm working on it.)

Hey @ryan is there something in the works in regards to findRaw and matrix fields? Right now they are quite difficult to handle as I have to call each and every field that is in one or another matrix types to get my desired results. blocks (my matrix field) - fields across some types Something like myMatrixField.* doesn't work - unfortunatelly. Another thing is that I can't query things like type for each of those matrix blocks. Is there a workaround or something upcoming in those regards? Asking for using ProcessWire as a Headless CMS with NextJS in a simple and light setup without GraphQL, RestApi modules or similar.

Will look into this - probably very soon - yet I still very enjoy this very module in my setups for quite some time now. Thanks @monollonom!

Super nice site. Just a thing I stumbled across: bluefox.studio/contacts/ results in a 404 (link coming from bluefox.studio/services/post-sound/) And there is this URL: bluefox.studio/SHOWCASE/ which probably should be in lower case like the canonical (incoming links: https://bluefox.studio/our-process/commercial/ & https://bluefox.studio/our-process/documentary/)

Dazed and Confused Communication Breakdown

Why not use a custom page name as a reference/ID across those instances? You could create those "on the fly" when someone is signing-up and therefore that "ID" would be unique. us-[timestamp]-{page->name} eu-[timestamp]-{page->name} Sure... using Page IDs is way easier, yet creating your "own ID" or using a "foreign key" could be an option. Needed this within a product catalogue (not users) but still. It worked out quite well.

Same here... used both in the past until now... almost each day I work with PW and forgot something however. Those are my most used bookmarks across all browsers. Maybe we (the Mods) could update the very first post or add an alert or something. Those resources are key!

What about we make this some kind of universal profile which works with webpack, bun, npm, yarn, vite... whatever. Or at least use this a guide for setting up all of those different setups. I never really used any of these tools - at least six months or so ago - right now I use NPM due to other tools I use now and therefore kind of started to like it (and as it's super portable through all OS I use, have to use or play around with). As soon as I am back at home I could provide a NPM/TailwindCSS/AlpineJS/browser-sync setup. Pre-Version of the mentioned above can be found here: https://github.com/webmanufaktur/processwire-addon-tailwindcss-alpinejs-barbajs

That domain is already taken as well. Yet... in case of domains... you should know who to ask first.

Here I am again... talking about ProcessWire while looking at other CMS... Has anyone of you tried? https://payloadcms.com/ https://directus.io/ While their feature lists look awesome right from the start, the backends look kind of basic - compared to what we can do in ProcessWire, while extending those seem like kind of a bit of work. No matter what. Yet... there are features we don't have in ProcessWire like default Rest API, GraphQL, and such. (Yeah... I talked about it a lot in the past.) Just asking for your feedback you have. Maybe insights for more details. So... anyone any insights about those? I will try those mentioned CMSs in the next weeks and therefore hopefully can write more about those compared to ProcessWire. If you ever used another CMS like those mentioned above or similar, let's talk about it. I'd like to hear more about it. (Don't worry... ProcessWire is still my absolute favourite CMS I ever used and use till today.)

That's true. The added description and details help a lot. When I looked into this thread there wasn't that much happening. A short intro and a link... which didn't help that much.

Checkout for what? Checkout with which providers? Checkout with which framework? What is your module doing? Don't get me wrong but... a bit more details would be nice. Maybe adding your README here would be a great start. Is this based on Shopify, Snipcart, Foxy or plain ProcessWire? I'd like to play with your module. Easy one-click-solutions are always nice, but... details and some kind of introduction would be really nice. Update: Details were added.

When you search for getSubmitActions you will find some thread talking about adding and removing buttons. At some places you can see how titles/labels of those buttons were set. As a starting point: Maybe that helps? https://processwire.com/talk/search/?&q=getSubmitActions&quick=1&search_and_or=or&sortby=relevancy

Woah... there are a lot of moving parts here. First of all: It always takes way longer than anyone expected it would take. I have seen super simple and minimal projects taking weeks instead of days. Yet I've seen quite large and complex projects that took only a few weeks instead of months. In average the PHP/PW part is most of the time the smallest part within a project that's just dealing with content at least in my projects. It can be tricky when you have to deal with lots of data from different sources, especially when you do more than just displaying that data. Most time and energy in my projects go into: Planning out the whole project Designing each and every bit Content audit, creation, and optimisation Frontendwork HTML, CSS, JS Right after that ProcessWire comes into play with these parts: Templates and fields Site structure, setting up basic pages Modules and global settings Backend logic, data automation, cron/lazycron jobs, automated maintenance On average I'd say it's a 70/30 ratio between those two. To get you some numbers here: We talk about at least a few weeks and maybe even months in total with all kinds of related things like meetings, phone calls, organizing, setting up Google and other tools, like tracking tools, newsletter, etc. To make things clear and a bit more transparent, we talk about projects and websites like these: https://www.restaurant-blechnapf.de/ https://www.klippo-nms.de/ https://www.musikschule-neumuenster.de/ In comparison to the above there are projects I built in my spare time without a lot of planning or almost anything - which took a few hours or maybe two days in total. Like these: https://www.jet-fire.de/ https://www.voss-friseure.de/ The main difference is that the first 3 projects are totally custom and fully optimized, multiple user accounts, access rights, automation and maintenance and design-wise on a totally different level. While the last two use UIKIT or Bootstrap, just display simple content and aren't that well optimized to be honest. Last but not least there are projects like this: https://www.restaurants-neumuenster.de/ It started with a simple splash page, a simlpe form and a bit of content and went online within a few hours. Yet as of today there are several hundred hours of work in it. Quite a bit design (had a few relaunches in the past) but way more in terms of data processing, automation, newsletters and lot's of nice things. TL;DR From about 2 days to a couple of months.

What kind of things are you doing with ProFields Table... I used it once... just for catalogue data entries, that's all. Never really saw any real benefit using that module. Is there something I missed?

You can either use the $sanitizer->truncate() in your template file or set a character limit from within your template settings. For the second option go to: Setup > Templates > Your Template Click on the textarea field (summary) > Switch to Tab: Inputs > Set character limit

In case you want a copy paste version to use RockFrontend with RepeaterMatrix from within a .latte file: {* templateExample.latte *} {foreach $page->repeaterMatrixField as $block} {$rockfrontend->render("fields/repeaterMatrixField/" . $block->type , ["block" => $block])|noescape} {/foreach} {* blockExample.latte *} <div> <h1>{$block->headline}</h1> {$block->body} <img src="{$block->image->url}" alt="{$block->image->description}"> </div>

Oh my... yes, I meant that. And I know why I wrote float at the end. Thanks! (I will update my answer.)

Details/data like vendor, seller, brand or similar could be set as a reference (page reference field). That way your data is super clean and easy to maintain (imagine a seller changes its name and you have to change it 100s of pages compared to one page when using references. This way you can also create individual pages or list for all those data-types - like a list of all brands, sellers, whatever you could imagine. I would create templates for whatever makes sense. Products get the product template, maybe even create different templates for different product types, like books, toys, movies. It depends a bit on what's actually existing in terms of products. Same with other templates. Maybe vendor and sellers are identical with the same details, so you could re-use that template but I'd personally would create separate ones just to have it easier with selectors later on. So you can right away look for vendors and sellers just by template name. That's in the frontend I guess. That's easy. You decide which part is a link, what data is shown and so on. In terms of template... the same. You decide which template is used at what point. What you are looking for is a float decimal field. You can choose this option while creating a field. What's the difference between promo and featured? Is there a voucher available when it's a promo? Either way it might be able to just use a checkbox. But that means you have to manually update all products that aren't a promo/feature anymore. The definition of new could be a checkbox as well or you use the created and/or modified date of a product page.

I personally use ProCache for that but it would still make an awesome feature. Multiple files or one single merged file... in the wrong hands both options can result in a slow loading site. So... yes, no, maybe. It depends.

Tried it again within a fresh ProcessWire instance and the most recent version of RockFrontend from Github. Installs without any issues. Doesn't even mention RockMigration anymore. Thanks! Edit: Another thing pops up now. Opened an issue on Github for it.

So... just made room for playing with RockFrontend and stumbled into this: Not really a deal breaker (the missing requirement) yet that message looks weird and out of place.

Well... in the past I looked up ways to get Twig up and running in ProcessWire and what-else-where and had to look up so many sources, details, guides and whatever that my urge to get it up and running diminished due to each and every step. Eventually I got it up and running, played with it, yet it was never backed from an "official" or at least "experienced" source. So I never trusted my setup. If I ever had a reliable source in the PW-Community that wrote, talked, spoke about it... I might have invested more time. Yet... there was noone. For whatever reason. Sure there were guides on modules, but not in detail. Or at least not for starters or dummies like me. You on the other hand are experienced in Twig, ProcessWire and therefore would have been a "source of truth" in some kind - if I ever would have had the chance to find a guide by you, I probably had way more fun with Twig and a ProcessWire/Twig combo. I don't wanna talk you into writing such a guide on your site or moving this piece of content as it is onto your site, but... even though it might be unpolished, not that detailed as other guides on your site... it would, could, should, might, whatever... drive people into trying it in a much easier way than struggling through lots of posts, tutorials or whatever. Maybe even Twig-users could find ProcessWire as their PHP-framework in this way. Who knows? Sure there might be more details needed but you know those details and could write at least an outlined article on how to get Twig up and running in ProcessWire. (Sure I know you work fulltime in an agency, with Craft CMS, ... ) Yet... you could. You know ProcessWire way better than me, and Twig as well, so... yes... I'd like to follow your guide or tutorial to get this up and running. You don't have to convince for me anything. My curiosity is already there - like it's by most of us here. On the other hand... I understand your feelings and thoughts about "it doesn't match the existing content" but... hell... it doesn't match most of the time. Wherever you look, whatever you write. Some posts are way more detailed while others are just basics. Yet... It helps. Probably. To make it short: Your inital post already convinced more to look into Twig in ProcessWire than any other post around - as it told me it could be used in a professional way. I thought about it in the past but maybe I gave up too early. So yeah... those were my almost last two cents on this topic.