cwsoft

@cpx3Are there any Javascript errors in the console? Seems you are using jQuery for the Ajax request. Maybe there are some conflicts with other JS libs.

Hi and welcome, How does your PHP script look like, what does it return as result on success or failure?

Hi and welcome, maybe you can provide some more details. Do you have a HTML template already? How many products do you need, what kind of categories, filters etc. How should products be added and by whom? Do you have a link to a eCommerce Shop looking similar to what you want? Have you tried any other shop systems already? Have you checked the PW module directory for solutions yet and checked if they include all the stuff you need like https://processwire.com/blog/posts/padloper-brings-ecommerce-to-processwire/?

Just for some further reading https://dev.to/walternascimentobarroso/dotenv-in-php-45mn

@Bernhard. Maybe a sort of never change a running/known system. Guess it‘s hard to leave an area where you have some profound knowledge for something new before the known systems shows it‘s limitations or starts to get annoying. Another big driver are customers, which are used to Drupals backend and workflow and avoid a change to something new as well.

Would also go with one PW install and one DB per website. PW is easy to update by just replacing the core files located in /wire (and .htaccess, index.php in the root), while keeping untouched all the stuff in your /site folder. DB migration is easy too compared to older WordPress sites, as no hard coded page links with fixed domains are stored in the DB. Really like how easy you can deploy a site developed locally to a live server.

Hi, you can bootstrap processwire in own PHP scripts following this howto https://processwire.com/docs/front-end/include/. For sure you could include the PW index.php script in your PHP app to check if a user has logged into the PW part of your site. But it wouldn‘t provide lot of features to access non PW user credential infos like login data of your App outside PW etc. Unfortunately the infos are a bit weak so I can‘t become more precise as I haven‘t fully understood what you want to achieve or what data you want to access from the non PW part.

Dear all, just released v0.0.5 of my EmailToEncryptedMailto module. The latest release adds support for regular mailto links. So with v0.0.5 all text emails and regular mailto links will be converted into encrypted mailto link variants on the fly. You can add a subject to your mailto links by adding "mailto:info@domain.com?subject=Your Subject" at the end of the email in the mailto part. Apart from that some further code cleanup. 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. P.P.S: Encrypted mailto links do not yet preserve class or id attributes. That will maybe added in a future release depending on customers needs.

@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.