TomPich

Hey @BrendonKoz, Thanks for the tip. No, I haven’t tried anything yet. Been busy these last weeks. I’ll try your solution. Thanks again.

Didn’t try it yet, no. I’ll do that and let the community know about it. Thanks for the lead.

Hey, The new version of PW (3.0.244/246) is great, and it uses TinyMCE 6.8. I saw that in this version of TinyMCE, there is a plugin that manages <detail> and <summary> tags. That was not possible in TinyMCE 6.4, used in the former version of PW (3.0.224). However, this plugin is not displayed in the TinyMCE input fields configuration interface. It’s just completely ignored. It can be activated though if you add it directly in the input field config in the database and it works perfectly. So it’s just a matter of user interface to get it straight in PW. Would it be possible to take it into account in the admin interface? That means see this plugin in the plugin lists of TinyMCE, and add the "accordion" button in the tool bar. Thanks

Hi Mtoro, And you shouldn’t... Once you are used to it, PW is so much better than anything else... 😊 I’ll share what I do (it’s not as "pro" as Bernhard solution, but it fits my needs and it’s simple). The good point is that PW database is not URL dependant. So you can dump it from the prod server, and import it on your local server, it will work as it is. When I have to do some modifications on a website that may receive some update when I work (like an order on an online store, or a contact form that has been sent), I do the following : download the DB from the prod and import it on local. use rsync to synchronize files from prod to local (I don’t synchronize the files in the site/assets/cache folder, nor the ones in the site/assets/sessions). modify the files that need it. If it involves some new fields or templates, I create them on the prod admin and export/import DB again on the local server. check if everything’s work well with FTP, update the files that have been modified (pushing with rsync may erase some new files on the prod version). As I said, it worths what it worths, but it works well.

Hello, Why don’t you just move the files and the database? You don’t need to make a fresh install. Unlike WordPress, the database can be moved as it is. Then you have to change the DB config in the /site/config.php file. Be sure to check if the old version of PW works with the new PHP version.

Thanks, but unfortunately, I tried these before asking, because it seemed logical. All of this return NULL. But it seems it’s because I try to do this in the constructor. It’s apparently too early for that. When I do that in a method, it works. So maybe combined with a hook, I can acheive what I want. class HomePage extends DefaultPage { public function __construct(Template $tpl = null) { parent::__construct($tpl); $this->lang1 = $this->languages; // NULL $this->lang2 = wire()->languages; // NULL $this->lang3 = wire('languages'); // NULL } public function lang(){ return $this->languages; // NULL return wire()->languages->getLanguage()->name; // works! return wire('languages')->getLanguage()->name; // works! } }

Hello, I was wondering if there is a way to access the $language variable inside my DefaultPage class. I’d like, inside this class to define a lang property, rather then in the page template. public function __construct(Template $tpl = null) { parent::__construct($tpl); $this->lang = $languages->getLanguage; // doesn’t work, $languages is not accessible inside the class } Thanks

Oh, that’s interesting... I didn’t know about that. I will try ASAP. Thank you so much, Bernhard!

OK, so it’s not Stripe. Every now and then, specialy in the middle of the night, I have the following exceptions logged: 2024-11-24 01:25:55 ? ? Unable to load Modules - SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: NO) (in /wire/core/WireDatabasePDO.php line 505) 2024-11-24 01:25:55 ? ? SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: NO) (in /wire/core/WireDatabasePDO.php line 505) Somehow, PW wants to use the local db credencial, even though it’s the online website. No error has been reported by my client, and I can’t see no error neither. Any clues about what this is about? Any help would be really appreciated. Thanks

Hi, Updating CSS – Processwire let you handle CSS the way you want directly in file(s). So yes, you will have to manually edit the CSS. I cannot help you with Form Builder specifically, as I don’t use it. But the general behaviour of PW with form is the same as default behaviour: if not specified otherwise, a form will send the form data with GET to the current URL when you press submit. So you have to check what method is used on your form (GET or POST) and to which URL the data are sent. With the elements you provided, I would say the data are sent with JS by fetch. So try to locate the script that handle this to see what happen when the form is submitted. When you know where your data are sent, there is two possibilities: • either it’s a existing page, so get the template php file of the corresponding page, and you see what happens with the data. • or (more probably in your situation, as it seems to be a JS submit), it’s an endpoint that has been created via a hook (check your init.php file in the site folder) to handle the data. Hope this helps.

Do you use structured data in your website? If you get no error but google tells you that, it’s the only cause I can think of now. If so, you can check their validity here: https://developers.google.com/search/docs/appearance/structured-data

I think I got it. I use Stripe on this website. And to confirm webhook, there is a POST request sent by Strip to confirm payment. When I do a test on the local website, Stripe sends the request to the online website, but with a reference to the local url... So PW cache is not involved here, I guess...

That’s my point. When using webpack on a website, you have to map the includes with the corresponding node_module folders. It does not find them automatically. That has to be done in the webpack.config.js. Otherwise (which is the solution I choose), you have to write the full path to the file to include (and the right version of it), something like "../node_module/@fullcalendar/core/index.global.js" or whatever file that provides the final "exports". Hope it will be usefull.

Sorry, maybe a dumb question to ask, but did you configure (resolve path / module to use, babel-loader)? Did you try that specifying the exact location of the files?

Yes, that would be great! Count me in (for Europe !) 😊