kongondo

Not sure if/how this applies to us. https://thehackernews.com/2024/12/new-glutton-malware-exploits-popular.html

Hi all, Just a general update regarding this issues. It seems to be related to a change in a ProcessWire version (thanks @Klenkesfor confirming). I'll continue investigating after the festive season break (early January). Thanks.

OK. Then I must have messed up somewhere. I'll have a look. Will have a play tomorrow. Thanks.

I think is the issue (i.e. the oversight in Padloper). I haven't used a setup like yours before but I am guessing calling $language on your site does NOT return NULL. Padloper uses this variable to check if a site is multilingual or not. So, Padloper thinks your site is multilingual. It then attempts to install 'padloper_description' as a language textrea field and things go awry from then on. You won't be able to do this. There is no option for this (but I could consider adding this as an option in future). For now, I will change language fields to check if corresponding language field exists instead of just checking $language. Would be great if I can test this on your remote test site, if at all possible. Thanks.

Hi @Klenkes, This is all very strange. The only common thing with recent issues is you guys are on Multilingual sites. The table 'field_padloper_description_pwtmp' looks like ProcessWire did not finish installing the table for the field 'padloper_description', i.e. the suffix _pwtmp is coming from ProcessWire. Not sure about the error with the tax rates field. It could be as a result of previous failures with respect to the description field. What are the languages on your site? Which one is the default? Can I get access to your remote test server so I can debug directly there? If yes, please PM details. Thanks for reporting this. Edit The only thing I can think of now is that the description fields fails to be installed (do you have language text area module?). For multilingual sites Padloper will install the description field as a Language Textarea field instead of a Textarea field. Maybe I should have a check for this module first instead of assuming that a multilingual site has this core module installed.

Hi @Klenkes, Thanks for the purchase. Sorry about the issue! I got the same error (incorrect table name) on a fresh install in a multilingual site with PHP 8.2 and ProcessWire 2.0.241. I am not sure whether it is coming from Padloper or ProcessWire. I wasn't able to find the root cause. In the end, I just refreshed that module page and the error went away. After that, I was able to install Padloper (configure) as usual. I didn't see the second error in my case. Are you able to please try again, this time refreshing the modules pages first. Thanks. If you manage to get to the 2nd part of the installation you will hit an error when you try to access the Padloper payment gateways, Stripe or PayPal. I have a fix on my end but not pushed that yet. You can implement the fix manually in your install like so: <?php namespace ProcessWire; // /site/modules/Padloper/traits/loader/TraitPadloperLoader.php // in the method getPadloperClassByName() near line #39 // FIND if (!empty($options)) { // stuff } // REPLACE WITH THIS if (!is_null($options)) { // stuff } Thanks.

Yes; version 010 is the latest 'release'. Spinbox is helping beta test the next version, i.e. 011 😃.

Haven't seen this too. I have 2 attributes (Colour and Size) with options of 3 colours and 3 sizes. I started with 2 colours and 2 sizes. I then regenerated by adding a 3rd colour and a 3rd size. No issues. Hmm...

Hey @Spinbox, @seddass, I have not been able to reproduce this (in Padloper 010). I can generate THEN regenerate variants. Fields settings for 'Selectable pages' works fine with the Padloper settings (i.e. padloper-attribute and padloper-attribute-option specified as templates respectively for the fields padloper_product_attributes and padloper_product_attributes_options respectively). Site: Multilingual Default Language: English ProcessWire: 3.0.241 PHP: 8.2.2 Please let me know your environment details. Edit: I do get a htmx 'selector not found in hx-include' JS warning but it doesn't affect anything. I'll fix this anyway Thanks.

Thanks for the tutorial @dotnetic In case someone runs into an issue I had, my Ubuntu 22.04 is the default distro in my WSL2. Hence, I did not need to enter the 22.04 part in my editor path (just '...vscode-remote/wsl+Ubuntu/rest/of/path/'. In fact, doing so leads to an error 'distro not found' (opens in a new VSCode window too).

Hi @itisnado, I have moved your question to its own topic in the Padloper support forum. This makes it easier for me to track issues/queries independently and more efficiently. To you question. That's pretty easy 😀. Indeed. Please have a look at demo 2. https://github.com/kongondo/Padloper2Starter/tree/demo-2 Please let me know if you need further assistance. If a hook has moved (I haven't updated the demos in a while), please have a look at the first post in the release topic for version 010. Best.

Hi @Spinbox, Has worked before 😃. I'll have a look. Strange. ProcessWire version? Thanks.

Hi @Velox111, Welcome to the forums! Sorry about this. Thanks for reporting. The issue looks like the class loader is not passing options and it needs to. I know where to look but please send over just in case. Thanks.

Hi @nurkka, Sorry about this. Could I please get backend access to the site to debug there? Great if it is a dev/staging site. Thanks.

This hasn't been my experience. DDEV shows both warnings and fatal errors. I haven't had to do anything special. What's your environment?

In case you need it, DDEV Manager for VS Code.

The integration of WSL2 and file explorer is very seamless. One can copy files between them as if they were on the same system. Even terminal integration is seamless. I never used WSL 1 so I don't know if it has always been like this.

I'd say give it a try. It's literally 2 steps. I did this recently. I didn't do step #3 there. Certs, multi-sites, etc., all work.

Anyone got xdebug + WSL2 + DDEV + VScode working please? I have read the tut in the DDEV docs but it is not working for me. In VSCode the Xdebug session starts. On the website Xdebug doesn't kick in. After a while, VSCode breakpoints turn transparent and hovering over them says 'invalid breakpoint' or something like that. I did attempt all the WSL-related troubleshooting in the DDEV docs, e.g. the telnet connection. Was hoping for a question here. After a while VSCode says port 9003 closed. Sometimes I see notifications from ProcessWire (e.g. headers already sent) in the debug output. I am not sure whether and how to append the port number 9003 to the ddev url. E.g. mysite.ddev.site:9003. If I do this, the website hangs (chrome website cannot be reached). Any ideas? Thanks!

For anyone reading this, I have been working with @Spinbox to implement a webhook solution + other backup (of session) solution. It is currently being (user) tested and has been implemented as Padloper 011. Will keep you posted!

I have recently had the same experience. In my case it looked like the culprit was DevSense PHP Tools. I gave up on it but the problem persisted with PHP Intelephense. Finally I gave up and went back to local development and set up a CICD with GitHub Actions which watches my main branch and pushes stuff to the server when main branch is updated. Works a treat!

Hello. Thanks for your work and report. Welcome to the forums.

What version of DDEV are you using? I know there is a recent update, 1.23.5. I am wondering whether this could be responsible for the slowness? I am on version 1.23.4 and have not upgraded yet (and running in WSL2 as mentioned earlier).

I see, thanks. In my case, the consideration is mainly if it can run an LLM locally without 'much fuss'.

M4 Pro beyond your budget or you have no need for the beast?