cwsoft

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.

Just working on a new module for a customer who is concerned about the wire frontend cookie set w/o prior consent by the user. The customer uses frontend forms which require session cookies (wire) e.g. for CSRF checks, input validation, failed attempt restrictions etc. So he wanted to show a cookie dialogue asking for consent for technical required cookies, even if this is not 100% required by the DSGVO. First used a modified PrivacyCookie module to achieve this, before I went to create a minimalistic module myself. My module hooks before page::render and adds a cookie consent dialogue which asks for consent for technical required cookies and shows an Accept/Decline button and links to imprint and privacy policy sites. My module also hooks into $config->sessionAllow and sets it to true if user gave consent, requested a backend page or a wire session already exists. This way wire cookie is only created in frontend if user gave consent. On the form page of my customers site the display and processing of the frontend form is wrapped in a $session->hasCookie() block to execute only after user gave consent. Without consent a message is shown that using the form requires cookies. By default the consent cookie is stored for 7 days if accepted, so the cookie dialogue won‘t show up on next visit unless user cleared cache. If user declined, the consent cookie expires after the browser session so the cookie banner pops up again on next browser session. So who may be using this module? Clients only using technical required cookies by default (no google fonts, youtube etc.) maybe with an optional frontend form, which are still afraid or simply want to have a cookie consent dialogue before the PW wire frontend cookie gets created. Will do some more tests and polishing, before uploading the module to my Github repository.

@bernhardIt’s on my list to install and test your modules once I find some time to do so. So far I looked into the code of yor modules on Github to get some inspiration and insights how the PW ecosystem works. Especially interested in the LESS template system. Used Twig (PHP) and Jinja (Python) in the past for medium to large size projects, while sticking to plain PHP/Python for small projects.

@bernhardIn my case I prefixed the Github repo with the suffix pw - as I plan to release at least one module more - but named the module folder and class EmailToEnryptedMailto without that pw suffix. I could add a ZIP package to the release section with the right folder naming convention, or just do it via command line inside the site/modules dir of my PW installation. git clone https://github.com/cwsoft/pwEmailToEncryptedMailto.git ./EmailToEncryptedMailto P.S.: May change the naming of the Repository in the future, but I do not think there will be much downloads of my module anyway, so I stick with it for now :-).

@bernhardGuess the core way is fine if you deal with just a couple of translation strings in one or maybe two PHP module files and only support one or two additional languages to the default English (like German in my case) out of the box. But this way may suck if you have 20+ strings spreaded over 5+ files and want to support 3+ languages.

@bernhardThanks for your suggestions. Fully agree with you on linked JS/CSS. In my dev env I use SASS/Typescript with bundlers to create one combined and minified CSS and JS file, which I include. Set it up like this so no one needs to modify templates or add CSS rules to template files manually. I also wanted something which just works without tons of settings you can apply e.g. add to head/body, add as inline/link etc. As there are at least three similar modules with lots of possible setting options, I just did a clean, small, tidy one with almost no settings at all as my first module. P.S. Thanks for the tipp with the install from url field, will check this out.

Updated module to version 0.0.2 with tranlations of the mailto subject text in English and German. In addition I added the CSS class automatically, so there is no need to add it manually to your template anymore.

Ok, managed to do it the ProcessWire core way by following the steps at the bottom of the Helloworld module by Ryan Cramer. Updated my first PW module for obfuscating emails accordingly.

@joer80Used various CMS like Joomla, TypoLight/Contao, Silverstripe, ModX, WordPress, WebsiteBaker, Plone, ProcessWire, …, in the past to build client websites. As a backend developer I liked Silverstripe, Plone and recently Processwire the most as they give you much freedom in doing things the way you like. The Processwire API is really outstanding here, as it allows to access/hook into about any process/resource you need with an easy to understand API. Don‘t know why, but from all CMS I used to build client sites, I hated WordPress the most. Used it only if customers wanted features or designs which where already available for free in the WP eco system. Best part for me was the automated updates of core and addons in WP. Most of my clients however want to host their sites on own servers and do not want to use cloud services or CDNs due to data protection requirements and general politics. In this eco system, PW is the perfect match for me as backend dev for now. And yes. Recent PHP 8.x features are really cool, especially if you used e.g. C#/TypeScript in the past.

@WarranDepending on what you want to achieve/include, AJAX requests may be used to load static texts (like cookie consent cards) as well.

@bernhardThanks tor the module. Have read about it on your Github/project site but as usual wanted to try the PW core way first. However I struggled what the core way is or the way it works. Initially I thought PW supports language files automagically by just putting a key/sprintf per line to translate into a CSV file per language/module. But than I checked out the hello world module and found there is an 'en' and a 'foreign' language column, a description and a hash. Didn‘t realize one needs another module to translate strings, as I never worked with__() functions yet.