Leaderboard

This is a reissue of a module of mine called "PublishingOptions", that I wrote a while ago. The big difference is that this module is written in PHP 8 and has some nice additional features. The old module could only publish and unpublish pages depending on date and time settings, but the new version goes much further. So you can decide what should happen after the publication end date has been reached. You have the following options: Unpublish the page - this is what the old version did Move the page to trash - new Delete the page permanently- new Move the page to a new position in the page tree - new The last option will be interesting if you want to move the page fe to an archive after a certain date. You can select the new parent page and after the publication end date has been reached, the page will be moved under the new parent page. You will find a more detailed instruction and download possibility at https://github.com/juergenweb/JkPublishPages This module is Alpha stage and should be tested carefully before using it on live sites. I have planned to add this module to the PW module download section, so everyone is invited to test it out and to report issues directly at GitHub. Thanx

And why should this be? As you can see from Berhard's example, it is possible.

Maybe a user permissions issue? It has happened to me that if the system user running the server cannot write the compiled processwire files (if compiled is turned on) it all fails. Though I do get warning in the processwire admin which you don't mention.

Hi @benbyf Maybe this module does help you too:

This week we've got ProcessWire 3.0.211 on the dev branch. Relative to the current main/master version (3.0.210), this version is 20 commits ahead. Many of the additions are user-submitted pull requests, and there are also several minor issue fixes too. Full details can be found in the dev branch commit log. I'd been planning on merging InputfieldTinyMCE into the core on the dev branch almost right away, but with so many minor fixes and improvements being added (that don't need much testing) we may put out another main/master version first in the short term, and then merge in InputfieldTinyMCE. Thanks for reading and have a great weekend!

Yes, but $input->post helps only when the data got send as FormData. But you can post data also as json in the body of request (fewer code in JavaScript). Native PHP example for reading them: // Takes raw data from the request $json = file_get_contents('php://input'); // Converts it into a PHP object $data = json_decode($json); Looks like PW has no functions. So I will use the native solutions from PHP. No problem ?

I saw differnt ways to handle ajax calls. I use 2. and 3.(for more complex projects) 1. Ajax folder with php files for each request, which include processwire index.php 2. URL-Hooks https://processwire.com/blog/posts/pw-3.0.173/#new-type-of-hook-for-handling-request-urls 3. AppAPI Module https://processwire.com/modules/app-api/ (Uses URL-Hooks or pageNotFound-Hook) 4. ajax.php template file https://github.com/kreativan/wirekit-core/blob/main/site-wirekit-core/templates/ajax.php 5. ajax request logic in each template file

LogMaintenance A simple ProcessWire module to give some maintenance control over log files. I found myself often having lots of log files for different things that can grow more or less quickly to a size where they can be difficult to maintain. The built in Logger of PW does a good job of giving you the possibility to delete or prune logs. But it has to be done manually and sometimes a log grows into millions of lines, which makes it often impossible to even prune it as it's too large. LogMaintenance uses LazyCron to run the maintenance task and there's several settings you can setup on a global or per log basis. Archive: will create zip files for each log file in logs/archive/ folder and add the log each time the maintenance is run to a subfolder containing the datetime. Lines: keeps logs to a certain number of lines Days: keeps the log to a certain number of days Bytes: keeps the log to a certain amount of bytes Each setting is checked from top down, the first setting to contain something is used. So if you check the "Archive" option, all other settings are ignored and logs are archived everytime the LazyCron is executed. If you want to keep your logs to a certain amount of bytes just leave all other settings to 0 or blank. Per Log Settings There's a textarea that you can use to setup a config for a specific log file one per line. All the logs you define here ignore the global settings above. The syntax for the settings is: logname:[archive]:[lines]:[days]:[bytes] errors:1:0:0:0 // would archive the errors log messages:0:10000:0:0 // will prune the errors log to 10000 lines The module can be found on github for you to check out. It's still fresh and I'm currently testing. https://github.com/somatonic/LogMaintenance

Here's one of my latest projects: https://petibol.pt/ Petibol develops and produces of all types of EPP (Expanded Polypropylene) and EPS components and packaging for various industries. This website is a collaboration between Supertiny and GOdesign. Super simple approach: The frontend is just SCSS and vanilla js "components" (no libraries), and pages are built with a blocks system based on a repeater field. Having tried a bunch of stuff between building this site almost a year ago and publishing it (Tailwind, AlpineJS, VUE...) it's pleasing to return to this site's code and compare the approach. Here I've basically set up Laravel Mix to compile SCSS, join and minify a bunch of <1kb js files. A BEM style approach to the styles so that I have a bunch of preset variables for typography, spacing and whatnot, and the JS files follow the same logic of identifying components like the hamburger or the parallax effect by looking for specific data-attributes and going from there. Super clean, performant, and couldn't be easier to pick up and maintain.

It does, it's just not documented unfortunately. I linked to information about it in my earlier post above. Here is a demo... Page structure: Field settings for subcategory field: "page.category" will be replaced with the ID of the page selected in the Category inputfield in Page Edit, whenever that field changes. The "has_parent" part is just to avoid unwanted pages appearing in the Subcategory inputfield if the Category inputfield is changed to empty (no page selected). Result: