Leaderboard

https://www.autohaus-bendel.at/ Highlights/Features: New Logo and matching Backend using module AdminStyleRock Very good google- and performance-ratings thx to UIkit and ProCache Flexible content pages (using private module RockMatrix) Cars are fetched automatically from an austrian cardealer API and converted into ProcessWire pages with a custom filter page: https://www.autohaus-bendel.at/fahrzeuge/ Forms with honeypots and live validation (using private module RockForms based on nette forms) Web-Coach The client gets automated reminders if he does not add new content to the website. Thx @wbmnfktr Bendel Web Coach The last news entry was created 21 days ago. There must be something new that will interest your clients ;) > To the website > Create news entry Animated page transitions using barba.js Migrations and deployment using RockMigrations. Debugging using TracyDebugger. ?

In general I'd say no, that's not a bad practice. Pages are built for storing data and they are built to scale. And they are built to work with all the nice things we have in PW world that are a pain to build with plain SQL database structures (like children/siblings/parent references and page reference fields in general).

Data is fetched via cron every night and then PW pages are created so that the client can enrich those pages with data that is not part of the API but is helpful on the website (eg a PDF sheet for the car or the point of contact): API-Fields are read-only. If a car is created by the cron and the point of contact is empty, the client gets a link to directly edit this page and select the POC ? If cars are sold, the cron automatically trashes those pages on the website. Ah... I forgot a nice detail! They have a custom branded PDF viewer:

Hi all, I've just put online on my server a new website, and I'm faced with an issue that so far I'm unable to solve. I've edited both the wire/config.php and the site/config.php to $config->debug = true; but when I go into Modules to add a new one, I always get this message: This issue doesn't appear in my local version, while it shown in my server version. I'm currrently unable to figure out any way to overcome this issue (ProcessWire 3.0.174). Can anyone help me solve this issue?

Just a quick one ... This is two questions in one. Integration: Probably not the answer you are looking for but literally any JavaScript library can be integrated into the PW backend. There are various options here including a dedicated ProcessModule or an Inputfield (e.g. a runtime one). Update data in real time. Any JavaScript and newer libs like HTMX can easily do this. The bottom line is this: (a) An action happens on the client (b) JS listens to that action/event (c) optionally but ideally, check if the action is valid (e.g. was this field completed) (d) send the info to the backend - usually via ajax for the type of app you are building (e) the backend processes the action you have sent including validation + sanitization. If these pass, it takes an action, e.g. 'create a page' or 'update a field' (f) the server sends the response back to the client which is listening for a response from the ajax request. Traditionally/usually, the response is JSON but with HTMX, the response is HTML. (g) The client handles the response, in many cases, updating the DOM. That's it. Yes. Media Manager, for instance. You drop files and it will upload the files then create media pages off of that. Yes. ProcessWire itself to be honest. Basically $input, $sanitizer, $config->ajax and $pages are the usual tools. Not a reuse per se answer. Listening to drag and drop using JavaScript used to be a chore. With modern browsers, APIs exist to do it easily in vanilla JavaScript. If you wish to get a ready made solution searching for JavaScript drag and drop will yield some results. Personally, I'd go for htmx + vanilla JS drag and drop, or htmx + sortable combo (here's a Python example).

This one looks cool: https://www.autohaus-bendel.at/fahrzeuge/300862-citroen-citroen-xm/ Nice site, BTW!

In case anyone else finds it helpful, I've been having major issues with both the original deprecated and later version of the module described in this thread not working properly with the latest builds of ProcessWire (>=3.0.200) and it seems like this module hasn't had much love in a long time, but after poking around on Github, I found a fork by @kixe that works for me. https://github.com/kixe/Multisite/blob/master/Multisite.module

@bernhard That's weird. I noticed in the database that it seems to create the columns "title1234" and "value1234" automatically. But doesn't RockMigrations overwrite that immediately after refreshing modules? I guess it's possible to check if the field already exists, then add the translations with some database magic. I've seen some promising functions in the ProcessWire folders. Maybe i can work something out. And yes, all that information helps greatly. Thanks! ?

When we released ProcessWire 3.0.200 one of the biggest differences from prior master/main versions was that PW now only includes 1 profile: the site-blank profile. This means there's probably going to be more people starting with it than before. Yet it is so minimal that I thought it deserved a bit of a walkthrough in how you take it from nearly-nothing to something you can start to build a site around. Everyone will have a little bit different approach here, which is one reason why the blank profile is a useful starting point. In this new post, here are some steps you might take when starting a new site with the blank profile— https://processwire.com/blog/posts/starting-with-the-blank-profile/

The notifications are part of the admin. PW doesn't get involved with your front-end output, so it's not attempting to provide anything with regard to notifications on the front-end. However, you can still use the API to add notifications to any user, but they'll need to go to the admin before they will see them, unless you provide your own output code on your front-end. If you wanted to output notifications on the front-end of your site, it would actually be as simple as this: foreach($user->notifications as $no) { echo "<p>$no</p>"; } There are of course several other properties, methods and flags that you can access from the Notification ($no) object. But outputting a notification is basically just a matter of iterating through the $user->notifications field and outputting them all, or just the ones you want. So in this sense, it actually would be quite easy to utilize on the front-end, but like with anything in PW on the front-end, you have to decide how you want the output to be handled. Currently it's using the same method as the forum we're typing in (IP.Board). I have not kept up with websockets technology lately, but was under the impression we weren't there yet unless you had specific client-side and server-side libraries to handle it and provide the fallbacks, or were using node.js, etc. I'd gladly implement websockets in the future if they enable us to accomplish the same thing more efficiently, easily and reliably without bloat. Last I researched this, we weren't there yet, at least in our LAMP context. But you likely know more than I do about that technology at this point, so interested in hearing more.