cwsoft

@bernhardWish days would have 30 hours so I could use 6 for testing stuff like your RockFrontend* modules while still have enough time for family, day job and spare time :-). Thanks anyway, sometimes I will test all your modules for sure, as your Github repos are already a big inspiration from a coding perspective.

Guess DeQuincy is searching for something different than my module NoCoWoCo. My module just shows a consent box for enabling or disabling technical required Cookies e.g. used for booking form validation etc. and blocks the wire Cookie unless user gave consent. Also not really required for technical Cookies, my client wanted to have this feature just to be on the safe side . So my module does not disable other cookies like Youtube, Google fonts etc. on users choice. Guess he is more after something similar to this project on Github https://github.com/orestbida/cookieconsent. Have used a similar solution for a plain HTML5 site with no CMS as backend.

Hi, what have you already tried? Not really understand your actual issue. So you have a landing page under path /lp/ and then I am lost? What updates have caused which problem? What do you want to achieve, what code are you using now, whats your PW version used …

@teppo With great power comes great responsibility :-). So far I got the impression that PW is a great tool for devs to create websites of any kind with an excellent API. As even template files are PHP files by default any non proper usage of PHP commands in templates, modules or hooks can cause serious entry points for an attacker. Guess most critical vectors of attack in 2023 are still not proper sanitized user input used in queries - even PW queries - or inputs output on screen without proper sanitizing in first place (e.g. CSRF attacks, reading JS Cookies or directory traversal). So yes, eliminating attack vectors is always a good habit devs should care about.

Dear all, just released v0.0.2 of my No Cookies Without Consent module. I basically added my Typescript and SASS source files and config files so other users can modify the minified Javascript/CSS code more easily themselves. Using Windows 10 and VS Code as my PW dev environment. The NPM modules used (typescript, sass, esbuild) can easily be installed as dev-dependencies via npm run install inside the module folder. Apart from that some code refactoring to avoid flickering of cookie consent on page reloads and some code clean up. I set the target of the transpiled JS file to es6 for better browser support (before it was set to ESNext). Have fun P.S.: The Github release section contains a ZIP-file containing just the ProcessWire module files without the DEV stuff included. The attached ZIP-file is the preferred installation option for end users, while cloning the git repo is the preferred option for devs wanting to adapt/modify the module code.

Dear all, just released v0.0.4 of my EmailToEncryptedMailto module. I basically added the Typescript source files and config files so other users can modify the minified Javascript code more easily themselves. Using Windows 10 and VS Code as my PW dev environment. The NPM modules used (typescript, esbuild) can easily be installed as dev-dependencies via npm run install inside the module folder. Apart from that some code refactoring and clean up. I set the target of the transpiled JS file to es6 for better browser support (before it was set to ESNext). Have fun P.S.: The Github release section contains a ZIP-file containing just the ProcessWire module files without the DEV stuff included. The attached ZIP-file is the preferred installation option for end users, while cloning the git repo is the preferred option for devs wanting to adapt/modify the module code.

@teppoSo far I used the core translation for two of my modules. I had only one to four strings to translate into German, as English was the default. I simply don‘t get used to translate the text inputs via backend form input fields per language, then create a CSV file from it and put it in the language folder of my module or template. Biggest hurdle for me seems that those language files are not automatically detected when another user installs my modele. So I need to guide users of my module how to install the supported module languages after installing my module. I would prefer just to throw in a CSV file per language into my module language folder without the need of a path/domain or hash value at all. So _t("English string") just uses the stuff from my module CSV file and falls back to English if the translation for the user defined language does not exist. Ideally I just copy the English CSV file, translate it to German and store it as de.csv. No need to translate fields via text inputs form elements or to install languages on top of the module installation. Would find it easier to translate just the CSV file e.g. via VS Code or Notepad++. P.S. However I am happy to have a core way build in I by default via _t() function instead of writing my own routine or dealing with language based arrays myself. Just would prefer a simpler way of translating my language files via text editor and to not need to install those files already in the module folder manually.

@BacosThanks for posting your solution. May come in handy for others experiencing similar issues.

Excellent. Thanks for your reply on that topic.

Forums often don't understand ironic, sarcastic or other kinds of conversations which normally do work face to face. In face to face conversations, your counterpart does not only hear your words (or read your text in the forum), but also sees the smile in your face or your mimic or gestures. Writting in formus gets even more difficult, if you need to translate things from your first language to a foreign language you learned 20 years back in school but with only little practice. Often the use of a smiley doesn't get the meaning of your text right if it was already missunderstood by the reader in first place. That is at least my experience in various forums ?.

Ok only one failed login followed by success is really strange. Haven't used simple form yet and build my forms with the core features so far myself. Maybe an update to the FrontendForms module from Jürgen may be an option, as it comes with lots of spam protection features out of the box.

I try to stay up with PHP/Python etc. like I do for my Windows/Linux systems too. So I would use PHP live cycle as a „target“. All EOL versions should be avoided for new projects or upgrades and not be promoted. At least try to update/recommend the lowest PHP version still maintained or at least still receives security fixes. https://www.php.net/supported-versions.php Personally I develop with PHP 8.1.x and test stuff with 8.2.x too so I spot possible deprecated stuff early. Similar to my Python, nodejs, npm projects.

@AndZykThe term „ideally should“ in German means one should at least try to target no warnings/errors or even blank pages in public Github main/dev branches in general - no matter what project it is. I have not written PW dev does not run with PHP 8.2 nor that I found errors or experienced a white page of death. I have seen some deprecation warnings some weeks back, thats all. Hope this makes things more clear. There is always a chance for getting things wrong in forums, especially if you have to write in languages other than your first language.

Even if you don‘t set/increase PW minimum required PHP version, the PW Github dev branch should be running PHP 7.x up to latest PHP 8.2.x at least without throwing warnings or even worse errors or a white page of death. Modules could than be tested and maybe a compatibility list could be set up for those older modules showing warnings or worse wouldn‘t run on latest PHP versions. Minimum PHP version guaranteed to work without warnings and errors (core) should be latest PHP 8.1.x, as most hosting companies allow at least to choose between the PHP version not having reached EOL yet. For upcoming PHP 8.3 the 2nd alpha is already available.

From PHP.net: https://www.php.net/manual/en/language.basic-syntax.phptags.php I read it as follows. While opening short tags can be disabled and are removed in newer versions, the shorthand echo <?= can‘t be configured, isn‘t (yet) deprecated and hence should work fine on older and latest PHP versions.

What users may not like about ddev is the need for WSL2 or Docker on Windows compared to e.g. XAMPP stack. Devs are often using Linux/Mac or Windows/WSL2 anyway, so this shouldn‘t be a big hurdle for devs, while it may be for users wanting to try stuff quickly on Windows.

PHP development has quite a momentum the last couple of years with older versions dropping out of the support line sometimes faster than users or hosting companies like. Some CMS/CMF already aligned their release cycle with PHPs cycle. Most hosting companies I know in Germany adapt quite fast to new PHP versions and often do not allow older versions more than one major release less than actual PHP version (8.x actual -> 7.x.latest last supported version). While full support for PW core for latest PHP 8.x will work quite smooth I guess, many of the third party modules are not updated regularly or are already abonded and hence may break. 10 years ago the PHP development speed was quite slow. Nowadays most hosting companies drop older PHP version anyway and you can‘t run PHP 5 on many hosts in Germany today. So I normally test my stuff with latest PHP version available and have latest 7.x for testing. I do not test anything below PHP 7.x latest anyway. So often some stuff I build won‘t run on old PHP versions. Thats why I put PHP>=8.1 in my modules.

Do they changed only PHP version or also other stuff like PHP execution (e.g. www-data)? Can you temporarily switch back to previous PHP version e.g. via .htaccess directive or admin panel of your hosting company?

Can you give some more details about your update process? What was the previous PW version, whats the new one. Have you updated PHP version or database in parallel? What was your update process?

Please note: I changed my initial forum name zx80 to my Github name cwsoft. Never thought I will release two PW modules within a month after my initial registration to the ProcessWire community forum ?. Hope this makes it more transparent for possible future contributions to the PW eco system.

Dear all, just released version 0.0.3 of my EmailToEncryptedMailto module including the suggestions provided by Bernhard. This allows to eleminate the class .cdc used to hide the span tags required to trick spam bots by the HTML attribute hidden. This way only one Javascript Caesar decryption file is added into the head. No more CSS needed. @bernhardThanks for the proposoal, highly appreciated.

@bernhardStill need to find some spare time to test your Rock modules, especially the RockFrontend module. What I read so far sounds great. Regarding the uikit framework. I haven‘t used uikit so far, but thats on my list too, as it is supported by some modules and the core as styling option.

@bernhardGood point. Hidden attribute has great browser support now, so I will remove the hidden class in the next version and replace it by a hidden attribute. Great suggestion, especially as this class is the only statement in the entire CSS file. Cheers.

Yeahh. I - or better my first ProcessWire module EmailToEncryptedMailto - made it into issue #475 of the processwire weekly news. Thanks to Teppo for your promotion. Highly appreciated.

After some more tests and polishing, the first version of my new site module NoCoWoCo - No Cookie Without Consent was released on my Github profile. The cookie consent dialogue will need some more love (like fade in/out CSS animations, darken background, maybe make it modal). A future version may add configurations for the links to the imprint and privacy policy pages (if exists), but this can easily be set in the module template file for now, so I don't know if it´s worse but we will see. Feedback welcome but not required of course. Have fun.