All Activity

@horst - there are lots of new theme issues being posted to Github

... I'm a bit late to it! 🙂 Used it first time now, and found some style errors on configurable module pages, when changing between "Light mode" and "Dark mode". Into which thread can / should I send this? Or have I to post it on Github? ...

@Spinbox I'm not sure why that wouldn't be working if the fields are initialized with a translate button. I've never nested RPB fields. I'd like to support whatever features RPB has. I've reached out to @bernhard to see if there's anything that he may know of to help or confirm that nesting is supported. Will come back with more info when I can.

Perhaps give $user->isSuperuser() a shot instead. It's documented as faster and is my go-to since it's a dedicated method.

Hi @All The condition should show these nav links only to logged-in superusers, but they are still visible to guests in incognito windows and even on other devices. Cache cleared etc. <?php if ($user->isLoggedin() && $user->hasRole('superuser') && $page->editable()): ?> <li class="nav-item"><a class="nav-link px-le-2" href="<?= $page->editUrl; ?>">Edit</a></li> <li class="nav-item"><a class="nav-link px-lg-2" href="<?= $pages->get(2)->httpUrl; ?>">Admin</a></li> <li class="nav-item"><a class="nav-link px-ls-2" href="<?= $pages->get(1137)->httpUrl; ?>">Analytics</a></li> <?php endif; ?> ProcessWire 3.0.246

Yes, I saw your post in this thread - but I hadn't (prior to posting) ssh'd into the host, and since the DDEV shell on WSL runs inside the WSL container I thought it was the live environment, and couldn't even find a /var/www folder. Once I used `ddev ssh` the pieces started to make a bit more sense. I hadn't tried searching for the symlink at that point though.

From how I understand it docker just doesn't know anything about the symlink if it's coming from the host, as if it's not even there. I think a way to confirm this assumption would be to ddev ssh, and navigate to htdocs, should be empty or with odd permissions? I use this trick to load composer libraries locally, but keeping them all in a central part of my host computer, I have a post about this somewhere around this thread.

Thank you, @BrendonKoz. Indeed, my multi-image field is called "images", and, as you see in my code snippets, all the attribute properties are in quotes (some in single ones, others in double quotes). Same in my real use case.

That did it! I assumed since WSL auto-mounted that I wouldn't need to mount yet again within DDEV's config, but apparently there's some other magic going on that I don't fully understand, and therefore this was necessary (I think it's how DDEV binds its own mounts within the various underlying containers). Thank you, @elabx! I'll probably adjust this solution a tad, but knowing how to make it work was the largest hurdle - thanks so much!!!!

I only have two guesses based on what you've shown: The $page->images isn't actually referring to your images' fieldname? Make sure that the name of your template's multi-image field is actually called "images". If not, change $page->images to whatever the field name is (so if it's named "pictures", use $page->pictures). Enclose the attribute properties in quotes. It may not be a problem for the source, but it would definitely be a problem for a proper ALT value. BAD: <img src=http://example.com/image.jpg alt=This will break your HTML /> GOOD: <img src="http://example.com/image.jpg" alt="This will NOT break your HTML" />

Hi All, I'm trying to create a simple gallery using the popover feature. Clicking (or touching) a thumbnail would show the large picture in the popover. See this codepen for a (reduced) example. In this case the triggers are just buttons (of class "trigger") lined up, each having a thumb image as child node. The popover image property src is populated via the data-full attribute of the button. This is working fine. But in my real use case the thumbnails are created in the template via a foreach loop: <article class="gallery"> <?php foreach ($page->images as $image){ $thumb = $image->height(180); echo "\n <button class='trigger' popovertarget='mypopover' popovertargetaction='show' data-full=$image->url > <img src=$thumb->url alt=$thumb->url /> </button> "; }; ?> <div id='mypopover' popover> <img src='' alt='uups' /> <button class='close_pop' popovertarget='mypopover' popovertargetaction='hide'>&times; </button> </div> </article> And here the src attribute results empty, the alt value remains 'uups'. I presume it's a scope issue of the variables in the function initGallery(). What am I doing wrong? Any hints are very welcome! Kind regards ottogal

Maybe you could try with volume mounting? This in .ddev/docker-compose.htdocs-volume.yaml https://stackoverflow.com/questions/57426306/ddev-mount-additional-folders-for-shared-composer-packages/57432155#57432155 services: web: volumes: - "/mnt/c/Users/brendonkoz/Dropbox/development/htdocs:/var/www/html/htdocs"

Hmm... Looking to give DDEV a try. Like Jonathan, I've had a setup that primarily runs multiple hosts from the same webserver, PHP, and SQL instance(s). Although it was Docker-based, it didn't require project isolation. Because of that, I've kept my files in a Dropbox folder, using the Dropbox client, so all of my local host machine's development files are automatically backed up and (minimally) versioned (Dropbox provides some level of version history). I'm using Windows Subsystem for Linux with DDEV, which automatically creates mounts for logical drives. Moving to DDEV, I spun up a config with the PHP, MySQL versions and web-server of choice (Apache) to mimic my production server. I also set the docroot to a folder, thinking that I might be able to create a symlink (as the /mnt/c/ contains access to the host filesystem, and therefore the Dropbox files) and overwrite the DDEV-generated docroot directory with a Dropbox symlinked project folder. After the DDEV config finished, I tested the project with a simple HTML file to make sure everything was working. (It was.) I then deleted the generated htdocs folder, and created a symlink from my mounted Dropbox's project folder to "htdocs" (the name of the chosen docroot). I am getting a Forbidden error. The file permissions seem to be set to 777 however, and the group and user match that of files generated within the DDEV container manually. I looked at the provider integration example where Dropbox is mentioned as part of the project's /.ddev/providers/ YAML folder, but I'm not using archived files, nor do I really want to have to pull/push/rsync any/all changes (I'd rather they were live since I'm editing them on the host OS, which the DDEV project can see thanks to the mount). ddev config --webserver-type=apache-fpm --php-version=8.2 --project-tld=loc --database=mysql:8.0 --docroot=htdocs From the project root, the symlink I used (for the first project as a test; my Dropbox "htdocs" folder is where I test random bits of code) was: ln -s /mnt/c/Users/brendonkoz/Dropbox/development/htdocs htdocs Does anyone have any thoughts?

[Update] StripePlMailchimpSync — v0.2.0 Hey, all, a fresh update for anyone using StripePaymentLinks together with Mailchimp! Version 0.2.0 adds proper resync tools, better reporting, and a few smart fixes under the hood. ⸻ 💡 What’s new Resync from the module settings You can now trigger a Mailchimp resync right inside the module config. Pick a date range, filter by buyer email if you like, and choose between dry-run or live mode. Each run generates a detailed report — showing who was synced, skipped, or caused errors. ⸻ Real-world use case: Your client’s been happily selling with StripePaymentLinks for a while — but only now decides to start using Mailchimp. With this update, you can sync all past purchases into Mailchimp in one go, safely and transparently, straight from the module config. Always open for feedback or ideas — if you’re using this in production, let me know how it works for you or what you’d like to see next! 🚀 Cheers, Mike

Has anyone figured out a reliable way to add a namespace to a module without resulting in a very stubborn error like: Class "WireData" not found Seems like the only reliable way is to uninstall and then install again, but this is kinda of impossible to do once you've already updated the files, so you need to know to uninstall beforehand. I have had requests to namespace my modules, but I don't want to break people's admin interfaces (and mine for that matter). Thanks!

Solved! As @matjazp advised in PM, mod_security was the problem. I contacted my host provider (OVH) and changed in .ovhconfig the line: http.firewall=security to http.firewall=none Thank you all for your time.

mod_security was the thing indeed! Solved thank you @matjazp @netcarver!

Thank you for this last tip @BrendonKoz, unfortunately, changing the admin URL didn’t solve that neither.

Yes, mod_security would be my first suggestion as well.

As I already told you in a private conversation, you should contact your host provider or turn of mod_security.

OK, understood. At the moment, it's being used on a feature which may not actually end up being actively used or by enough people to make it worthwhile fixing those sorts of issues. We'll have to wait and see.

You'll need to do more than that to make it reliable - have a read through some of the issues - these two are key. One is simple to fix, but the other requires a fair bit of work. https://github.com/ryancramerdesign/LoginRegister/issues/2 https://github.com/ryancramerdesign/LoginRegister/issues/9

Yeah, that's what I ended up doing, removed the restriction on the page-create roles.

Hey @rooofl, I saw your request for help. I unfortunately don't do client work, but would still like to offer at least one additional chance for fixing this issue. It doesn't seem like this client is a Dreamhost customer, but it's entirely possible that the host may have similar configurations for security on their server. You may want to reach out to, or have the client reach out to, the webhost support team and ask if the URL as provided in the network devtools that you screenshotted would cause their server security to prevent the request. For Dreamhost, the solution was simply to change the custom URL for the administrative panel from whatever custom option (ex: "admin" in your screenshot's case) back to the default of "processwire". This is due to their custom mod_security rules. They can update their rules for one-off requests, but the next time they update the server software it'll break again. Here's where I mention it: It's worth a shot to, at least, try changing the admin panel URL from "admin" to "processwire" and then testing an upload to see if it fixes things. Otherwise a support ticket to the webhost would be my next suggestion.

@FireWire Thank you for this amazing module! I'm using RockPageBuilder (6.7.0) and the latest dev version of Fluency. In some cases I use nested Rockpagebuilder fields (So a Rockpagebuilder field inside a Rockpagebuilder field). In this specific case the translated values aren't saved (unless you edit the fields after translating, as you mentioned earlier).