Leaderboard

Others have mentioned how to do it in the Markup or in $config. If you wanted to do it using JS, this is how: document.body.addEventListener("htmx:configRequest", (event) => { // add XMLHttpRequest to header to work with $config->ajax event.detail.headers["X-Requested-With"] = "XMLHttpRequest" }) https://htmx.org/events/#htmx:configRequest Not meaning to hijack this thread and I haven't read through everything and I don't know how Markup Regions work...just want to mention that I have set up a GitHub repo for htmx + Alpine.js + Tailwind CSS + ProcessWire demos. It is early days but I am hoping to add all sorts of demos there, from basic to advanced ones, including backend and frontend examples. I'll create a thread for this work at a later time. Meanwhile (and I have nothing against the OP wish), I am happy to take on a challenge like 'how would you build this complex page using htmx' . OK, maybe not as complex as this app: From React to htmx on a real-world SaaS product ?: (too much todo, etc.). Edit First two demos are discussed in this thread:

Amazing! I'm so happy for Carson!

Off topic: htmx is in the first cohort of the GitHub Accelerator: https://github.blog/2023-04-12-github-accelerator-our-first-cohort-and-whats-next/

There's

I think this is a great idea and would love to see it implemented. Of course you could achieve this with partials, if statements etc. But your proposal would make things much cleaner imo. Great resource. Thank you for putting this together.

Hi, I had integrated ViteJS a year ago or a bit more, it could be used to build for example a dashboard, or even a website, but the main issue I faced was to make Server Side Rendering working with all the setup to be able to get better SEO/ranking. That's said, SSR code was done this morning ?? The test below was made on a non optimized Caddy setup on Windows with sad php-fpm. I built a javascript package which will be published on NPM to give you a smooth experience to integrate Vite into ProcessWire. I have to build a ProcessWire module to make thing even easier instead of putting some file in our template dir, that will be made asap as it doesn't require lot of work. It's also shipped with InertiaJS which I find no point of not using it, but could be used without it. Everything can work with Svelte Framework (I am a big fan of it, I feel like coding web on the 2k years), React work also, and Vue should work without hassle as any other frameworks/libraries. Just saying, but his one I think will not be much of interest for you, I also built a solution which replace Electron for building desktop application based on native code (Pascal) and JavaScript bindings, where ProcessWire is used as headless cms (I think I had already spoke about it in some threads), it could be used as is without the need to put your hand in native code. I'm curious to hear what others in the ProcessWire community think about using ViteJS for your development. Have you tried it before? What has your experience been like? Please share your thoughts and feedback in the comments, and feel free to vote in the poll below to let me know if you're interested in more tutorials and resources on this topic, like profiles, themes. And pheww, I am quite happy! ?

Yeah, sorry, been talking about the PW logfiles of course ? That's why I posted it in "PW general support" and not "dev talk", but I changed the post title to make it more obvious, thx! Now I understand the answer of @wbmnfktr better ? I'm not sure yet if I really like to auto-prune logs to a given size/length/age... I think I'd prefer to get an email when logs grow too much. Do you have some code to share with us?

Since bernhard didn't clarify, I think he's referring to ProcessWire logs, not system or server logs. My host handles rotation of server log files, but not log files generated by scripts installed by me; does yours (that'd be both neat and scary!)? So, I believe the maintenance being discussed here are the log files found in site/assets/logs/*...? Thus far: deploy and forget, but now I'm going to have to look!!! I'd personally be fine with keeping logs to a maximum number of days old. If I wasn't around or didn't check on something more than 30 days prior it's unlikely I'd be interested in it - though that's just me.

Just another guess... what kind of setup is that production one? Standard Apache or maybe NGINX or CDN in-between there somewhere?

That’s what I do. Part of a regular cron batch job.

I'm reviving this. @LostKobrakaihas nginx vhost confs in this gist: https://gist.github.com/LostKobrakai/b895e2e0e8a2c14b4da88cc7e16cf954 Just wondering if they are up to date with the latest PW .htaccess rules? What seems to be missing are 16A and 16B which are needed for better control over multilang installs with UTF-8 page name support. When I try to run those through available online converters it results in garbage. Not having enaugh expertise in .htaccess or nginx vhost configs. So any help would be much appreciated.

Looks like bogus to me. Get those once in a while as well. I have Git running on most instances. So I can easily check any file changes. Oh... and when someone wants Cr*pto... always check if the exchange rate does make any sense.

not security hole files .in /site/assets/cache/HannaCode not web access-ible so no need to die()

I know I'm cutting corners here, but in my opinion that distinction already exists: "site" and "core". This should be easy enough for a client to grasp, though of course you may need to explain it (at least) once first ? ProcessWire is by design a modular system, even at the core level, and hiding that would mean that you are hiding a defining architectural design decision and — arguably — advantage over some other systems. If you need to go to such specifics (I haven't, and in fact I have never granted client access to modules at all, though that's of course more about business model; if the client hosts and maintains the site, they will need full access) I would argue that it's better to explain how and why this is actually a good thing, not an issue ? Meanwhile (again in my opinion) "site" modules are third party modules, regardless of who developed them, though of course it's not a huge stretch to argue that those built by Ryan are 1st party. If you want to signal that Ryan's modules are from the project architect/lead, I guess that could make sense. Still sounds like an oddly specific requirement from the client, though, and I would again explain why some "official Pro-modules" are used ?‍♂️

@Pete, This is now ready. I have done two demos. In the first one, Alpine.js populates the modal with values that have been passed to its $store. These include details about a product's variants, client-side calculation of total price, etc. htmx adds to cart and displays success message. In the second demo, htmx populates the modal with values it fetches when the modal opens (via 'buy now'). It then passes the values (via the returned markup + x-init) to Alpine.js $store. After this, it is the same as the first demo...and htmx updates the cart and displays success notice. I was hoping to do a video demo + tut but run out of time. I'll do a better explanation here (or in a different thread) or in a video later. For now, the most important things to note are: I was hoping to do some very basic examples but got carried away with these demos. I hope to do very basic examples with very minimal markup in future. daisyUI is used here for its Tailwind CSS components (e.g. the buttons, modals, etc.). Stating the obvious here, but it is not needed in a final project. Note the folder structure in /templates/. Demos are in their respective folders in /templates/demos/. Although I would have wanted a simpler folder structure so as not to confuse, it wasn't easy to pull that off given that this repo will host various demos. I didn't want to create multiple templates that display the same thing. Hence, the demos .php files do the rendering and the handling of the htmx request for their own demos. This means the template 'products.php' remains clean and just loads the current demo's .php file (a render file, so to speak). The folder /templates/data/ has JSON of the fields and templates used in the demo, in case you want to test in a separate site. _func.php has a number of utility functions including one which can fetch dummy products from the Fake Store API, and use these to create products and categories. Selecting a demo automatically reloads the page. This is achieved via a redirect passed to htmx. Viewing the frontend will greet you with this, very colourful shop! I went wild with all the available daisyUI themes. The current theme can be changed using the select at the top left. This is persisted using a plugin by Alpine.js called persist. It plays very nicely with $store and x-data. Whereas it is very easy to use things like x-data with local data within a component itself (e.g., <div x-data="{ open: false }">), given the size of the demos project as a whole (now and in future), I decided to handle and store most of the Alpine.js stuff in a main.js file. This separation of concerns helps in the long run. All libraries are pulled from their respective CDNs. There are lots of comments in the demo files. Whilst this makes the files longer, hopefully you also get to understand what's going on. Most things are necessarily named verbosely. Things should be very clear. The demo site itself is not finished. E.g. currently, we only have a very basic template if viewing a single product. There is very little attempt to hide my ineptitude with respect to CSS ?. Any questions, just holla.

@Peter Troeger This should work: foreach(wire('languages') as $lang){

Hi @artfulrobot Have you seen this thread? Does it answer your question?

Is each and every language module installed? Languages Support LanguageSupportFields LanguageSupportPageNames LanguageTabs Just did this in a clean blank installation, added a second language, and added this to one of the templates: <?php echo __("This is my translatable phrase."); ?> No issues at all. When I remember correctly there were issues in the past with some PHP versions but thats long ago. Another thing could be a missing namespace declaration. Or... try to copy parts of the multilanguage site profile over. https://github.com/processwire/processwire/tree/master/site-languages/templates The docs: https://processwire.com/docs/multi-language-support/code-i18n/

Hello, I've just had little time... so I write a short post and come back later I thinking about organize my (visible) pages for example at "/content/*". So I'll get links like "/content/about" or "/content/myPage". Is it possible to create a path alias like "/about" or "/myPage" without the parent "/content/"? Finally I try to get a tree like this. [home] /content/ /tags/ /categories/ /settings/

I have a "Person" template, with fields for FirstName and LastName. There is no need for this page to have a "Title" because the title should always be "LastName, FirstName". I have successfully created the hook to do this -- when you publish, the Title of the page is set to "LastName, FirstName" and the page is saved. Then I hid the Title field on the Edit Page screen. However, PW still requires that you Title the page when you first create it. So, you are asked to enter a Title, URL segment, and select a template. Is it possible to suppress the Title field on the Add New screen? I think this is going to be hard, because on that screen, you haven't even picked a template yet, so PW has no way of knowing you're creating a Person and should therefore not enter a Title. This is a specific example of a more general problem -- when the Title of a page should be formed from structured data found in the template definition, how do you handle the apparent need for an editor to enter a Title which will immediately be reset? This is a training issue -- you could explain this to editors, but they'll find it confusing ("So...when do I enter a title? On this one? Why not on this one?").

Hey all, I guess I will just write here instead of starting a new topic. Did anybody manage to implement something like that? More specifically I would need title and name field to be pre-populated when creating a new page ($page->title = $page->parent->title & $page->name = "temp_".$page->title). I was planning to do it via hook in module, but I have no idea which hook would do something like that. Page name would than be renamed based on some field value (which I guess is simply done using "before save" hook). Thank you all for your help! EDIT: OK, it was actually really simple solution. I solved it by using "one-step page add" solution from above, then I used a "saveReady" hook to rename page title and page name. The only problem that remains now is how to check if user changed the title after. In other words: how to check if the title that is present now (before the page save) is the same as the one in the database. $page->field outputs the one from db and I don't know how to access the one from the form that was just typed in. I tried with $input, but it doesn't output anything. Any ideas? EDIT 2: So the answer to my last question (if somebody will need it) is: When attaching something to saveReady hook, one can access form values (on a new page dialog) via: $event->arguments('page')->data['field'] For example to get to title: $event->arguments('page')->data['title']

I've added a feature on the 2.4 dev branch that several people have asked for in the past: 1-step adding of pages. To enable it: edit the template used by the parent where you want to support 1-step adding of children. In the 'Family' tab, in Allowed template(s) for Children choose the single template you want to be used for children. Once you do that, you'll see a new box appear below it, titled Name format for children. You can enter any text that you want here, and the page names will use it. If the name causes a collision with another page, then an incrementing number will be appended. You can also enter just the word title if you want it to base your page name on the title field (when you later populate it), or you can enter a PHP date format to base the page name on the current date and/or time. More details This screenshot explains it all. Look at the "Allowed template(s) for children" field and the "Name format for children" field. There are drawbacks to 1-step adding of pages, which is the main reason we've not supported this in the past. The biggest drawback is that you can end up with a unused pages due to accidental clicks on an add page button. To reduce this problem ProcessWire assigns a temporary status to pages created this way (Page::statusTemp) that gets removed as soon as you save it the first time. Pages that remain statusTemp will be automatically moved to the trash after having that status for 1+ days. Of course, pages created this way also have Unpublished status, so they aren't going to be showing up on the front-end of your site until you publish them (like any other page you create). The second drawback is that you are skipping over the page naming step, so pages have to be named automatically (which is what the Name Format you specified is for). Of course, you can easily change the name to whatever you'd like from the 'Settings' tab of any page. I've removed that drawback by adding the "title" option. When used, it populates your page with a temporary name and then re-populates it with your page title when you save. For most situations, you'll probably still want to stick with the 2-step page adding process. But for situations where you'd find it worthwhile to have 1-step, you now have the option.

$config->httpHost should do the trick

I agree. The Title field will exist, but I will set it automatically every time the page is published. Behind the scenes, the data will be there. I just need the user to not have to set it.

The problem with removing the Title field is that this leaves the Add New page in a weird state -- no Title, but a Name field (the URL segment). Since there's no Title, the Name doesn't get set automatically, so you're asking someone to input a raw URL segment (without one being suggested). It looks odd, to say the least.

While you can un-global that title field (which I don't think I've personally done), I think it's not a bad idea to keep it around as a standard when possible. I've setup things like you are talking about before (company directory), and I'll usually re-purpose the title field on the "person" template to contain the "full name" or "last name". You can change the labels for the fields so that it identifies itself as something else by changing the field context in the template editor. You might also want to make use of the template "family" settings to define that when adding a page to say /company-directory/ it will only accept children using your "person" template. That way you aren't selecting a template when adding a page there.

WillyC's example just modifies the output of the $page->path() function (which is also used by $page->url). His intention there is to change what URL gets sent out when you call $page->url. It's really no different than making your own function and using it instead, except by using a hook like this, you can continue to use ProcessWire's API and get the result out of it that you want. Ultimately it's just a syntax convenience. While his hook example handles the URLs that get output in your markup, you still have to have something to look for and capture those URLs. Perhaps you could use mod rewrite, but typically you would use the "URL segments" feature that you see on the "URLs" tab when editing any template in PW admin. Lets use a simple example of your homepage template (home) with filename home.php. And lets say you want to make it so that when someone access domain.com/contact/ (a URL that doesn't currently exist) you want it to display the page that lives at domain.com/about/contact/. So you are setting up your site to respond to the shorter URL of /contact/ (rather than /about/contact/, where the page actually lives). Go to Setup > Templates > home > URLs. Click the checkbox to "allow URL segments", and save. Now edit your /site/templates/home.php file, and do something like this at the top: if($input->urlSegment1 == 'contact') { // render the /about/contact/ page echo $pages->get('/about/contact/')->render(); return; } else if($input->urlSegment1) { // throw a 404 throw new Wire404Exception(); } // otherwise continue normally and display your homepage.

Joshua, I am in no way 'expert' when it comes to PW, but one thing I've learned so far (and one to keep in mind, maybe I should make a nice print ) is that developers often apply traditional CMS thinking (for things like tags, categories, etc.), and that gets in the way of the flexibility of the PW Tree. You often need to step back, visualize the target outcome and try to create tree that gives you the outcome.

WillyC's solution is a good way to go if you have this need. But want to mention that the whole idea of multiple routes to a page kind of goes against the grain of the ProcessWire philosophy. By design, there is only one URL to any given page. This is different from systems that disconnect their data from URLs (Drupal, EE, etc.). ProcessWire considers pages like files on a file system. We are trying to embrace the way that the web is addressed rather than counter it. I understand the desire to make a shorter URL for a given page, and that's a fine reason to implement a solution like this (and I've done it myself too). But the reason you don't see things like this outlined in the documentation is because I don't think it's a best practice, whether in ProcessWire or on the web in general. So if someone uses multiple routes, I would suggest it only to solve a specific need after a site is produced… not as something to build around from the start.