cwsoft

@PWaddictHave not yet used SimpleForm myself. If a human scans a site and modifies a bot, most forms can automatically be filled I guess. Seems there is no counter for failed submits logged by IP or general wrong submits yet implemented, which would limit the amount of trials to lets say 5. Thats something I always want to have in frontend forms to protect my side against bots and script kiddies. FrontendForms and the pro module from Ryan do implement such protection by default if I remember right. How many failed trials were in the logs before the success message appeared? Only one failed, than success? That would be strange.

Hello, after reading forums, old PW weekly and reading through language support docs and Ryans HelloWorld module, I am still struggling to add two translations in German and English to my own module. How would I create the CSV file(s) with description and the hash (md5?). Is there a module used to create the language files, or just create manually? If manually, how is the hash created, or what string/values are used as input to the hash function? Any tip, hint or link would be appreciated. I must have overseen some important parts so far. Thanks in advance.

@Vineet SawantForm Builder Pro from Ryan (commercial) or at least with FrontendForms from Jürgen (free), if the project will be realized with processwire. However as Jim already pointed out, you should take some time to invest in the requirements and the best tool around to achieve what you want. That may involve another framework, coding language etc.

Hi, have used the site/config.php $config->allowSession handler in combination with the PrivacyWire module to disable frontend cookies unless the user opt-in to accept technical required cookies for a booking form shown on my frontend w/o user login required. The booking form is not displayed and processed until user opt-in. Instead a message is shown that the booking form requires cookies to work. The other pages can be viewed but with the consent form displayed. Once the user opt-in, the PW wire cookie is created and the booking form can be used as normal. Don‘t know if that is really necessary, but that way should be ok with the lawyers out there in EU/Germany. P.S.: If Url contains backend path, sessions and cookies are enabled by default. Its just disabled for the frontend guest users by default.

Just uploaded the module files to my Github profile in case someone is interested in. If you want to use it, just download the attached Zip file in the Github Release section of the linked repo.

@flydev: Damn red pill ?. Created my first module hooking after Page::render and replacing text emails like (example@domain.com) into encrypted mailto links which gets automatically decrypted from a Javascript function embedded into the head section if emails are found on the rendered page. Really enjoy my PW journey so far. If you need more options, want to configure stuff from the backend etc. I propose you try out the EMO module from Roope. My module will stay like this without more profound checks like mailto: links, embedded emails in other tags. If you are interested in the code, just send me a PM or post here.

As strftime is deprecated and it‘s alternative is a bit overshoot to me, I tend to just create an associative array with the short Weekday names like $shortWeekdays = array(1 => 'Mo.', 2 => 'Di.', …, 7 => 'So.'); and access them like $shortWeekdays[date('w', (int) $page->getUnformatted('datefield'))]; Just put this stuff in my _init.php file so I can use it where I need it in the template files. If I would need multilingual support, I would create an associative array with the required language codes like array('de' => array(1 => 'Mo.', …), 'en' => array(1 => 'Mon.', …));

Thanks for the link, didn‘t knew this site. As I am still new to PW I am still in discovery/experimental mode. To learn a new CMS/CMF I always try to use core stuff first and see how far I get by adapting things like templates, modules myself rather than jumping into 3rd party addons right from the start. Once I get more familiar with PW ecosystem, I test out 3rd party addons and check their code base to see how others would implement stuff.

Almost. Guess I will turn my working solution in a custom text field type sanitizer first so there is no need to „hack“ the template files anymore. But really nice how PW stays out of your way and allows you to test/implement ideas very fast and to refine/adjust the POC later. Also like that it‘s up to yourself to use procedural or object oriented code or a mixture of both similar to Python for quick tests. P.S.: I knew there is a PW module available to obfuscate email addresses, but I was curious how long it would take me to port over an working solution from some older projects of mine to PW myself.

Hi, just ported over an old mail encryption/decryption routine using a Caesar cipher from some old projects to protect email addresses from spam bots, but show it normal for humans into a ProcessWire module. How it works: Enter email with double brackets where you want it [[example@domain.com]] in any CKEditor field Turns to <a href="javascript:cdc('dbfnrgmzfumx','SubjectX')">example<span class="hidden">(</span>@<span class="hidden">)</span>domain.com</a> A Javascript function decrypts the encrypted email on click Link is obfuscated from bots, but visible for humans (example@domain.com) Email placeholders are automatically detected via template _init.php file Placeholders gets replaced in template _main.php by wrapping $content around a PHP function Was super easy to implement with Processwire using the Intermediate / delayed output template strategy of the advanced default PW template and the great API. Super fun. P.S.: If someone is interested, I can post some code examples too.

@Jay DYou could try to hook into the page save event via the ready.php file to create/update images of a given page/template. Not dealed yet much with image manipulation myself. But doesn‘t the default image field allow to manipulate the image already. Coding wise you could use the image API https://processwire.com/api/ref/pageimage/size/.

@netcarverThanks for your reply. Will most likely deactivate Cookies in frontend, unless you are in admin/backend, or the user checked the confirmation in the frontend form to use CSRF protection. Most likely in combination with a user consent module asking for permission. Your posts and links helped a lot to understand the background to get things done.

@flydevThanks a lot. Exactly what I searched for. Will try to play around with those settings. Regarding lawyers. Interesting post, but stuff may differ in Germany. The lawyer of the company I am working for has a completely different view of what Cookies are technical required and what Cookies are not ? Cheers.

Hello all, is there a way to prevent the creation of the Processwire frontend Cookie wire until the user has confirmed/opt-in to allow technical required Cookies? Not too sure, if the wire Cookie is technical really required for PW to do it‘s job (show frontend stuff, remember layout etc.). In Germany it‘s still a bit fuzzy, what technical required means to a lawyer. So ideally there shouldn‘t be set any Cookie without opt-in by the frontend user, unless it is really technical required. Can anybody shine some light on this aspect? For what is the wire Cookie used in the frontend layer, or in other words technical required by the PW frontend? What parts - except admin/backend - of PW wouldn‘t work without that cookie? Looking forward for some hints on that topic.

Just to let you know. Todays demo was a full success. Online booking project will enter next testing stage. However it‘s not yet decided if the project will be realized with PHP/MySQL and Processwire, or Python/Django as the companies internal CMF/CMS of choice used for about 80% of all internal projects.

For WordPress sites I used the Plugin Better Search Replace to replace hardcoded Urls when transferring Sql dumps from localhost to my live server and vice versa. For other CMS I just opened the Sql dump in Notepad++ and did a search/replace of Urls to match right host.

@BoostGuess you talk about converting WordPress site to PW site - right? Would just develop as usual using localhost for the new PW site and then just upload stuff to the server once ready. Usually I have three site/config.php files (config.php, config_server.php, config_local.php) which just differ in the DB credentials and the root host. Once my localhost PW site is up and running, I zip it (.htaccess, index.php, site/ and wire/) and upload the zip file to my server via Ftp together with a simple PHP unzip script. Then I run the unzip script on the server. Than I cooy/rename site/config_server.php to config.php). Last step is to enter my server PhpMyAdmin and just delete old DB tables and import the sql dump from localhost.

Cool. Will test this option too, once I showed the demo to my client and it was decided if and how to proceed with the project. You guys are all awesome and gave me a lot of tips, hints, links and code snippets to check out. @AndyThanks for your sanitizer snippets, already using those on all input data by default. Even do whitelisting whenever appropriate in addition.

@netcarverThanks, already implemented a simple SESSION based math spam protection myself and some honeypot fields. However my client is very paranoid about DSGVO etc. He even worried about the guest Cookie (wire) set by PW by default on startup, even I tried to explain it‘s a technical required cookie set by the underlying CMS, which gets deleted automatically when the browser is closed.

@flydevThanks for your suggestions and links to posts and code examples. Highly appreciated. Got the idea and philosophy already partially by Bernhards YT video, which brought me to PW first place. Was about to start with pure PHP/MySQL, HTML/CSS/JS. Pretty sure I wouldn‘t be that far, as I did my last serious PHP/MySQL project about 5 years ago. So far I am pretty happy with PW and I know I just revealed the absolut basics yet. Looking forward what more to come in the future.

@flydevThanks for this suggestion. Already thought about this too. Guess this would indeed be the best approach. However I came up with another option, as the entire PW booking site should also not show up in Google at all. I simply hid the entire PW side behind a .htaccess AuthBasic login. I may update my PW PHP script creating the booking pages to add .htusers credentials as well or just use a global AuthBasic login for all of the 100-150 users and a unique BookingID per user. So far I am good to go for a limited internal test, just two days ahead of the deadline for the concept study ?. However I will play around with PW frontend login and the FrontendForm module until the project goes live, as I think that‘s indeed the way I should go, as PW already adds security measures for free. Thanks for all your suggestions so far. Highly appreciated.

Hi, just added a fifth option to keep Google and unwanted users out. I Just hid my entire PW booking side behind a .htaccess AuthBasic access. But will try the FrontendForm module too as it seems to already provide all the features I want to implement myself already out of the box ?.

@horstThanks for the tutorial. Still useful for newbies like me. Now I have a German backend too, great!

@AndZyk: Thanks for your input. Will try first with the free FrontendForms module as I am quite new to PW and do not have a lot to deal with web dev recently (more C#, Python stuff for Windows Desktop). Hence I don‘t want yet to spend the 179€ for the pro module unless I will know for sure using PW more often in the future. cheers zx80

@bernhardThanks for your reply. Video was this one Process looks like this. About 100 people get an E-Mail with Url to the PW booking page and a personalized random BookingID (40 random chars) which is not guessable. This part is out of my control and lets say historical grown. The people can check for about 10 events in 2024 and subscribe to one event using their personalized bookingID. Due to data protection concerns, I am not allowed to store any personal data like E-Mail, Name etc. online. Not in PW, nor in textfiles on the server. Thats the constraints I have to fulfill. Hence I wrote a script, which creates 100 booking pages (one per person) which holds the unique bookingID and stores the subscribed eventID and last access time when the form is submitted. Every week a CSV file is created by PW which gets imported into a master Excel spreadsheet (historical grown) to check who subscribed for what event. Thats why I can‘t hide the booking form behind a PW login form per user and hence want to make the form more robust against spam bots and script kids attacks. If I would be free, I would create a different solution, with 100 login pages in the PW backend and without all the hassle of freakling around with Excel sheets at all. But I was really impressed how far I got over the weekend with my first PW installation setup on Friday afternoon last week. But I agree. It‘s important to understand the concept of PW of everything being a page with fields assigned via templates. Thats different from many other CMS I used in the past, but once you got the idea, it starts to make sense quite fast. Cheers zx80