szabesz

Can't wait! :) +1

No access from Hungary or many other places form the globe either. US and Canada based VPN access works. I suspect that only North America is allowed.

It is definitely not, I agree. I think even the introductory blog page does not make it clear what the purpose of DefaultPage actually is: https://processwire.com/blog/posts/pw-3.0.152/ And a lot more could be documented and supported, see my old thread, for example:

Interesting but I find it hard to digest this chart as being a useful overview. I keep looking at it and fail to "keep anything of it in my brain". I find the following "cheat sheet" much more informative and therefore usable: https://addyosmani.com/blog/script-priorities/

Yes, I refactored my code by using URL hooks which is much cleaner anyway. Maybe. I could dig up the old code to take a look at it but the issue is not important anymore. Thanks for you support!

I should have checked first if there is new version of the module or not, I was banging on open doors... Thanks anyway, the new hookable method is very useful, and not just because I can now save custom data but because I can also skip logging saves performed by hooks only (by setting $event->return to null when a field is only changed by a hook and not by a person).

Yet another pretty useful module from New Zealand. Thanks a million!

That's strange as it does work for me. Did you double check everything?

@teppo It's me again :) I wonder if you could somehow make it possible to optionally log more data in "$details" via hooking into the process, by more data I mean some filed values that has been changed. if (!empty($fields_edited)) $details['Fields edited'] = implode(", ", $fields_edited); https://github.com/teppokoivula/ProcessChangelog/blob/49c35bb65ae5642401df062168fa6f4a69dfbf75/ProcessChangelogHooks.module#L595 My use case is that such a feature could make it possible to do detailed debugging. If I could store some additional key data change, then I could reproduce what exactly happened, so that I can replicate the exact issue. Of course, I could just put logging all the data I need in my on code, but having your module do that instead would make an integrated solution.

@franciccio-ITALIANO Can you please also wrap your code in the "Spolier" block as I requested? Very long posts make it pretty hard to see through a thread. The "Spolier" block hides its content in an accordion so that we can manually open it at will.

Hello, You should paste in here the exact code of your _main.php, preferably hidden in a spoiler block of this editor (use both the "eye" and the "code" icons of the toolbar). That way we can have a better understanding of the issue and ask further questions.

FORMATTED VERSION: in my config.php file $config->contentTypes = array_merge($config->contentTypes, array( 'css' => 'text/css' ) ); this adds the css file type in your template "files" tab / content-type select then, on top of my bibicss.php file <?php namespace ProcessWire; header("Content-type: text/css; charset: UTF-8"); header("Charset:utf-8"); and i linked to my bibicss page the usual way in the head of the pages that need it and it worked fine i think that would be the same for js files with a simple 'js' => 'text/javascript' and the correct headers Content-type in the template in case it helps have a nice day

Hello, You can do this: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-copies-of-the-same-module Maybe I'm missing something, but how can one accidentally upgrade a module? Besides, if you think that is an issues, your backups and/or git versions, etc... should cover you, shouldn't they?

related: https://codingpad.maryspad.com/2013/07/19/interview-with-ryan-cramer-processwire-cms-founder-and-lead-developer/

Currently, the site I mostly work on is running ProcessWire 3.0.213 and PHP 8.0.x with 62 third party modules. I do not have a single issue which is worth mentioning, so I'd say this is certainly a "Peace-of-Mind Setup". Note that around ProcessWire 3.0.214 and ProcessWire 3.0.215 Ryan has started some heavy refactoring in the core so I would not call current dev versions "Peace-of-Mind" even thought he has fixed a lot of newly introduced bugs since then.

Thanks for sharing! As always, your contribution to ProcessWire and its community rocks!

Also worth noting:

In a perfect life, yes. But is it perfect? :) Jokes aside, as PHP development has been speeding up recently, I do not think it is realistic to expect Ryan and module developers to keep up with that pace. Luckily, I do not have such an experience but I would blame hosting companies for being so rigid. It is not they who have the burden to upgrade PHP websites to be able to run on PHP 8.1 or higher, so why do they force anyone to do that in the first place? I would also blame the PHP core team for not providing security fixes beyond one year: https://www.php.net/supported-versions.php While I agree that new features in PHP are welcome, I do not think they are so essential that I could not live without them for a few years more, if I wanted to. "if it ain't broke, don't fix it"

I would not recommend setting ProcessWire's PHP requirements too high. Why would that help? If anyone wants to use PHP 8.1 or higher then that's fine but why should we "punish" those who cannot switch just yet? Why would "unifying" the required minimum PHP version help in any way? You cannot "force" module developers (who share their modules for free) do that. Am I missing the point, perhaps? BTW, I always use ProcessWire two versions behind the up to date major version of PHP because I do not want to deal with deprecated issues. I do not have time for that, and it saves me tons of time not to hurry just because...

Hello guys, Read the forum rules please: https://processwire.com/talk/topic/8234-community-rules-guidelines/ I am thinking of this: "The forum language is English. We really appreciate the effort everyone makes from countries around the world to post in English. After careful consideration and experience on other forums, it makes sense to have one common language for discussion here so that ideas can be shared and not missed in language-specific forums - the same applies for debates that might get out of hand as we do not want to miss those either."

@Inxentas Another option for the frontend is https://unpoly.com/ which I use these days. Using Unpoly one has to write less code compared to using HTML+Alpine.js.

Hello @monollonom, I updated the site I'm using this module of yours from v1.1.8 to the this RC version and could not notice any difference. I do not know if it makes any difference or not, but I'm using the module with the "Bypass cache for superusers?" option turned on, because as a superuser, I will ever be the only one to have the module convert MJML to HTML. It is because I am using it for generating HTML templates for transactional emails which are only changed by me. I implemented a simple interface in the admin for rendering and previewing requested MJML templates which are first saved as HTML files and after that parsed for some simple "custom template tags" I made up, so that tags can be populated with actual values and the whole email can be sent in the end. So these MJML templates rarely change (except during development, of course) and that's why I do not use caching at all. When sending a transactional email, its saved HTML template is used. cheers Szabesz

I also have a 100% working spam protection technique I always use (and nothing more). See it working here: https://www.szepelet.com/about-us/contact-us/ Human Detection is a pure PHP random number, rendered by :after {content: attr(data-attr);} and the css class is deliberately not named with a related term, just to make it more obscure. No bots have been smart enough to crack it so far.

Sure, until I bought PphStorm years ago, which spots this (and more...) and warms me right away.

Thanks for the detailed reply! I see now that such a feature would not be feasible. You must be right. I was just wondering if it is always a good idea to let the module kick in no "matter what".