Leaderboard

A note to myself.. I think a good example could be to build the Skyscrapers demo using this dev stack.

Yes I will do that contacting the module's author or maintener! I will updates in here again.. when I have more information of #PageListBetterLabels. Sorry my little knowledge... I cound't gave a proper explanation. I really like this complementary module as it is unique.

This week updates continued with various .js files in the core (for jQuery 3.6+ compatibility). A few external libraries were also updated to the latest versions, including jquery-tablesorter, jquery-ui-timepicker, magnific-popup and vex. And finally, InpufieldTinyMCE has been added to the core! That's a lot of updates, but there's not a lot more to write about these updates because we covered the jQuery updates last week, and InputfieldTinyMCE has been the topic of several past posts. But now we've got everything together and running smoothly in ProcessWire 3.0.216. I think we're now ready to focus on getting the next main/master version out in the coming weeks. There likely won't be an update next week because I'll be traveling for a few days, but will be back to a regular schedule the following week. Thanks for reading and have a great weekend!

We've been running pretty much the same jQuery and jQuery UI versions for the last 10 years or more. I haven't really seen much urgency to upgrade because the versions we have work quite well, and I wasn't so enthusiastic about the amount of work and potential headaches the upgrade might entail. Over time there have been been a few security issues found in the jQuery library, which I've always kept an eye on, but they weren't ever things that affected our usage or caused any concern here. The biggest hangup I had was just that upgrading meant also updating a lot of code that uses jQuery, since many of the changes to the library are not compatible with code written for earlier versions. (Newer versions of jQuery have a slightly less convenient API than earlier versions). I place more value on stability than on having new versions of things. But it's always been in the back of my mind that sooner or later it would be nice to get these libraries upgraded for many reasons. After all, newer means better and faster right? Well, not always, but that's been the theme in jQuery at least, that newer versions of the library have some performance benefits over older versions. For awhile now, ProcessWire has been using newer jQuery version only when $config->debug = 'dev'; and I've been testing that out for quite awhile (maybe a year?). This week we upgraded our "main" core jQuery version from 1.8.3 to the last available 1.x release 1.12.4 (4 years newer), which is the one I've been testing. We also upgraded our "dev" jQuery version from 1.12.4 to 3.6.4, which is the newest available version, released by jQuery last month (March 8, 2023). In addition, our jQuery UI "dev" version is now updated to the newest available version, 1.13.2. After awhile, these "dev" versions will become our main versions, but likely not before the next main/master version. While the core seemed to work fine as-is with the newer jQuery (1.12.4), the newest versions of jQuery (3.6.4) and jQuery UI (1.13.2) required quite a few JS file updates to support, and that's primarily what you'll see in the commit log this week. If you'd like to test the newest versions of these libraries in the ProcessWire admin (in a dev environment), edit your /site/config.php file and set: $config->debug = 'dev'; When you do that, it will also load the jQuery migrate library with logging ON. Meaning, the Javascript console will contain messages about things that need to be updated. There's still work to do in the core here, so if you enable 'dev' mode then chances are you'll see some messages about things in the admin too. The "dev" debug mode also makes it use the newest jQuery UI library. Keep an eye out for any visual glitches or any UI things that don't work. For instance, I found that when using the newest jQuery UI version, the image resize/crop tool wasn't working quite right, though I hope to have that figured out soon. Chances are there may be other examples like that, if using the 'dev' debug mode, so please let me know if you come across any. If you are a module author, your module uses jQuery and you want to make sure it's working well with the new main core version (1.12.4) you can also enable jQuery migrate verbose messages in your javascript console by setting the following two in your /site/config.php: $config->debug = true; $config->advanced = true; I've found that updating code for jQuery 3.6.4 seems to be backwards compatible with 1.12.4, so maybe just using the $config->debug = 'dev'; option is a good bet when testing, but I wanted to mention both options are available. I'll be continuing to update our core .js files for 3.6.4 and jQuery UI 1.13.2, and next week will likely update some of our 3rd party jQuery libraries such as the TableSorter library and others. Also, I've not forgotten about pulling InputfieldTinyMCE into the core, that'll likely be in the next version 3.0.216. Thanks for reading and have a great weekend!

Very very very interesting!!! @flydev Really appreciate your time put into this answer. The running SSR app generates it's own static stuff if the update in the content requires it, am I assessing this right? I'd love to test an example! Let me know if also I could be of any help.

in my config.php, i setup an empty array for siteSettings like this: $config->siteSettings = array(); then in my ready.php file i'm array merging some values from a settings table (profields table), in the admin like this: $st = $pages->get('/settings/')->settings_table; $settings = array(); foreach($st as $row) { if(!$row->value) continue; if($row->disable == 1) continue; $settings[$row->setting] = $row->value; } $config->siteSettings = array_merge($config->siteSettings, $settings); i'm curious if anyone sees any possible issues with this; it works now and i can access my siteSettings everywhere doing this;

Don't mind, come back as many times with as many doubts as you have. Yes there are amazing modules put out by the community!

Okay understood. About the dev environment, I must say that it's not intended to change your habits. For example, my usual directory structure of my web folder containing the index.php/site/wire is the following: . └── /var/ └── html └── example.com ├── build/ssr/ssr.js <-- run by NodeJS on the server ├── wwwroot <-- directory sent to server hosting │ ├── site │ │ ├── modules │ │ │ └── ViteJS │ │ ├── assets │ │ │ └── static <-- contain assets built by vite │ │ │ ├── layout.abc123.js │ │ │ ├── home.abc123.js │ │ │ ├── about.abc.123.js │ │ │ └── ... │ │ ├── ... │ │ └── templates │ │ ├── _func.php │ │ ├── home.php │ │ └── about.php │ ├── wire │ ├── index.php │ └── .htaccess ├── src <-- development directory & files │ ├── styles │ │ └── app.scss │ └── js │ ├── components │ │ ├── Button.svelte │ │ ├── Hero.svelte │ │ └── ... │ ├── pages │ │ ├── Home.svelte │ │ ├── About.svelte │ │ └── ... │ ├── app.ts │ └── ssr.js ├── .env ├── package.json ├── vite.config.ts ├── tailwind.config.cjs ├── tsconfig.json └── ... The structure can be tweaked as you want. In this example, I'm using TailwindCSS, and Svelte. When developing, the result in your browser will be refreshed when you will save the modified file (it's called HMR for Hot Module Replacement). The same thing will happen when you will modify your ProcessWire templates files. In dev mode, files are served by the vite's local dev server. About your question about the "autobuild", with Vite you have basically three commands. Take a look at the following scripts section of a package.json file: "scripts": { "dev": "vite", "build": "vite build", "preview": "vite preview" }, When you will run `npm run dev` for example, vite will start the development server, the build command will build the production files, and the preview command will start a local server to serve the built production files. You are free to set up any workflow you are interested in, for example like throwing a build on each HMR event (I've given an example about that on stackoverflow, see https://stackoverflow.com/a/69632090/774432). On my side I am mostly working with private servers, but behind the scene the workflow is quite "the same". On my server, I run on closed environment a simple node command `node ../build/ssr/ssr.js` , where eg. on Vercel, you will want to use their Node.js Runtime features through an API. As I said, you can keep your habits in terms of editing content, let them log in ProcessWire backend and filling their body field. The update/preview is just a matter of refreshing or changing page on the site you are working on. The change is dynamic, you are not required to build or commit any change, and as always, you keep the freedom to make only the content you decide to be available - it's a bit , I made you an example on the bottom of the post. I do not use it and I don't remember how it works, but if you can pull data without markup, then all is ✅ even with markup it should work. I will test it. Enregistrement #52.mp4

For all that are interested in testing, I have created a PHP7.4 compatible version at https://github.com/gebeer/RockMigrations/tree/repeatermatrix-php74 It just so happens that I needed it urgently on a live project where I couldn't change the PHP version in time ?

Thanks for all of the work, Ryan! I hope you enjoy your travels!

Great stuff! Good to stay up to date!

@bernhard It wasn't really a website. It's a catalog of machine parts for the company. We were then looking for a CMS that could display the hierarchical structure of the catalog well. In addition, we needed the templates to have a different structure for different types of parts. One of our young programmers at the time said: there is a great American CMS - ProcessWire, it is perfect for our task. That was in 2012. In any case, we finished this project in 2012. I found a backup now. We used ryancramerdesign-ProcessWire v 2.2 In 2013, we moved our windsurfing store project from a self-described CMS to PW 2.4. By the way, the self-written CMS has been around since 2000. At that time @Soma cheatsheet helped us much. We still maintain that project, but have updated PW each time for new features from @ryan. Back then, there was no PW module for a full-fledged store. But in 2012, @apeisa published an example of such a module Shop-for-ProcessWire. We took it as a basis and now it is a working online shop. In fact, I made my first site in 1994, and it is now also converted to PW. It was such a long story with a happy ending.

Hey everyone, there is a new module AppApi available which is based on my original RestApi module but has some additional features which are really cool! I have been struggling to find time for the RestApi module over the course of the last 1+ year, so I'm really glad @Sebi is stepping in and doing work in this area. I think it would be a good idea, to see AppApi as a successor of the RestApi module and put all focus and development efforts there. What do you guys think?