BrendonKoz

Good catch. Definitely an oversight in the template code itself. The old version does not wrap all elements in an anchor tag. Comparable example.

Coming from my own redesign that used a very, very bright non-white background color (to lessen the burden of contrast on the eyes), I agree with this. As much as an off-white may be slightly more soothing to the eyes, it's very difficult to make it look fresh, or clean, because we associate pure white with that, for the most part. It can be done, but is far more difficult to accomplish from a design perspective. That said, it's still just a preferential bias. 🙂

I suspect it has to do with the new $files->unzip class method(s) (assuming it's part of dev version 253): https://github.com/processwire/processwire/commit/3f15400643a8c8eecf39b59144d94553fb876bcd I'm not yet running that version, but for those that are, if you wanted to dig down into the rabbit hole to discover where some inconsistencies might lie within the code, I'd start there.

@MarkE's module is masterful. I'm really, really glad he developed it. Even if I haven't (yet) used it, the benefit that it can provide in certain situations is immense. I'm glad that mentioning it helped out!

Have you tried to re-add the module files, and recreate the table schema (hopefully the data wasn't necessary) to see if it would be enough to provide a state that removes the errors? The ini_set errors are likely showing simply because errors are being output to the browser prior to a header() call being made; standard issue when errors are displayed in PHP. Fixing the errors should fix the ini_set warning.

Fix confirmed. Thank you!

The FieldtypeMeasurement module might be another option (I haven't used it myself yet, but it appears to offer time conversion). It may need some massaging to allow the interface to behave the way you want, but I'd think it would assist you quite a bit. I saw in the module's README that it has second, minute, hour, day; I just don't know if it offers (out-of-the-box) microseconds. The combination input values might not default to the formatting you'd want to provide end-users. Honestly, I'd probably just use a text field and handle the calculations myself, unless they have strict database requirements or comparisons that you'd need to do in the future. Just in case this is useful for your project (referencing a now-fixed rounding issue with Float values in PW):

Hi Robin! I haven't yet identified how/where this is occurring, other than that it is. In a repeater field utilizing a TinyMCE-enabled textarea field, the (I assume) JavaScript injected icon and tooltip seem to be rendered twice. I'm seeing this in both ProcessWire v3.0.246 and v3.0.256 on PHP v8.2 with module version 0.1.3. Not a big deal, just thought I'd report it.

Yes, I saw your post in this thread - but I hadn't (prior to posting) ssh'd into the server/guest machine/container, 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.

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" />

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?

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.

The website, permacultura-cattolica.it, appears to be working as expected right now. It's possible your computer browser's cache is remembering things incorrectly...? Can you try from a different computer (phone?) or browser just to verify? Either that, or you've fixed it, based on @virtualgadjo's suggestions (which sound correct to me).

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?