wbmnfktr

Woah... yes! They do the trick for me. These settings are hidden pretty good. @cpx3maybe you try the above mentioned setting. It works for me in my current setup. On a side note: just noticed that this issue doesn't occure in Firefox (115.0.2) and only in Chrome-/Chromium-based browsers.

As the title pretty much says... my TinyMCE always adds an almost empty paragraph (containing only a nbsp) after saving the page. I have to manually remove it via Source Code view to have it fixed for that moment. The next time I edit the content the paragraph gets added again. In total I have to save a page twice. I tried to find a setting or plugin that does that and even disabled lazy loading. No chance. The only setting that fixes this issue is using the inline editor and not the normal editor. But that's not really an option. Has anyone encountered this issue as well or maybe even knows a nicer fix for it? ProcessWire: 3.0.221 PHP: 8.2 Profile: PW Multi-Language Field export below: [BEST SOLUTION FOR ME SO FAR]

I'd fake it and use a selector like this: $pages->find("id=1")->each('<li><a href={url}>{title}</a>');

Short follow-up: it's perfect now!

Absolutely! Even their Twitter account is having fun right now and ThePrimeAgen is on board of course. https://twitter.com/htmx_org https://www.youtube.com/results?search_query=primeagen+htmx

As there are already a few fans of HTMX here - just to let you know: htmx 1.9.3 has been released https://htmx.org/posts/2023-07-14-htmx-1-9-3-is-released/

This would be awesome! I was afraid you would say that, yet I almost knew it. On the other hand I wanted to mention such an addition for your fieldtype. Since my last post I tried a few things more and there is another thing I found... would it be somehow possible to wrap days and times in individual <span>s or define a dl instead of an ul? My goal is to make it look like a table, which is not possible right now - besides using the array version, which isn't that handy - but would work probably. On the other hand... your JSONLD output example is absolutely perfect for what I can tell right now.

I just started playing around with this module, and so far it's really nice. There is just one thing that is a bit weird for me, as I don't really need that holiday entry. Is there a way to hide it? Sure, I could use showClosed=false, yet I'd like to list all days of the week, as it makes it way easier to read and compare. Another minor thing in regards to that holiday option that came up while playing around... would it be possible to somehow add a label to it and add up to 5 or more entries? For example, if I wanted to add Christmas Eve, the 1st and 2nd Christmas Day, New Year's Eve, and New Year's Day, That would be 5 days for which I would either need a date or a label, so everyone knows exactly what days are meant.

Are those different to the ones in the standalone VS Code extension?

Future-Proof involves a bit of work on your side. Future proof just means, it could and will probably be a solid setup in the future, either with your knowledge or changes brought in, or by PW/Ryan/Module Devs. See below, please. If you are not THAT into PW or PHP... future proof or all-in/DEV setups might not work for you. You chose to use an experimental* setup of PW/PHP. * some kind of non-official setup right now (2023-07-05) The combo you chose is somewhat in-between everything right now. IMHO. I had quite a lot of issues with that combo and therefore moved to my Peace-of-Mind of setup in most cases. [Disclaimer] I AM NOT A PROGRAMMER, or even a DEV - since 2014 I just use and work with ProcessWire. And it works for me. I know almost nothing about PHP, besides echo/foreach/if/else and similar. And some details about PHP in general. I do concepts most of the time, sometimes frontends (nowadays), and in the majority SEO, Marketing, and such. So... yes... you still get those issues for whatever reason in some setups. That's why I mentioned my personal Peace-of-Mind setup above. (as it totally works for me without any issues - and I am not an example for anything in those regards) As @bernhardmentioned... contact that module dev and let them know there might be something wrong. A PR/issue report is probably the best way to communicate that, AFTER contacting that DEV directly in one way or another. PRs with a solution at hand... always a great way to contribute. SO... even though you got errors/warnings ... you helped to find issues to make PW more FUTURE PROOF and maybe even DEV setups. That's awesome. (as mentioned in some other thread, I can't find right now: PW and PHP are moving quite fast right now... issues are a thing, but the outcome will be worth it)

I am totally aware of this. Yet, the combo of PW 3.0.210 and PHP 8.1 wouldn't be my first choice right now. But... this will change with the upcoming new stable version of ProcessWire. That would be a totally different story. It is, still it's nothing I'd recommend right now as the foundation of a project. Not because it's not working, but because I don't know if the person I recommend this to can handle a few warnings and issues once in a while or would then just trash talk about ProcessWire because of it. That's the main reason I never recommend any All-in setups. To be totally clear: if I knew you or the person better - for example someone like @bernhard - I'd probably suggest using PW DEV on PHP 8.2 actually.

Peace-of-Mind Setup: ProcessWire 3.0.210, PHP 7.4 Future-Proof Setup: ProcessWire 3.0.210 (or latest stable), PHP 8.1 All-In Setup: ProcessWire DEV (always latest), PHP 8.2 If it was my own project to play around with ProcessWire - 3rd option. If it's a small client project that once it's built never sees an update again - 1st option. If it's a long term project with lots of functionality, lots of content, nice budget - 2nd option.

I have seen this or maybe a very similar warning a few times - not with DDEV as I only use project abbreviations and not fully qualified domain names there. So your project would be running as something like brk.ddev.site here. Chrome is fine with that. Possible solutions: don't use full domain names use abbreviations instead write it domain-tld instead And always remember the ddev.site part is a fully qualified domain thats registered and everything. So technically yourproject.ddev.site is/could be a real subdomain and due to some security features Chrome tries to verify that this subdomain is secure and everything.

Grab one of your used font files (woff, woff2) and upload it to: https://wakamaifondue.com/ It will check for all kinds of features and details. Look for the tnum feature.

It's not that wrong but maybe not the best option in this case here. I'd honestly go a totally different route and... create a template catalog_image or something create and add all necessary fields to that template create another template catalog_category create and add all necessary fields to that as well From there I would create all category pages and add those images under each one/where necessary or wanted. That way you can always move one image to another category, sort them way easier, disable, or clone one with ease. Oh... and it's probably way easier to maintain.

A bit weird and probably nothing to listen to while programming - still awesome.

Mau P @ Academy - Los Angeles 2023

Absolutely. Even though I didn't know that page was so... outdated while being up to date. Arguments for my thoughts and feelings. 👏 I really think the cut must be bigger - see my last post. But YES.

My absolute favourite tool for developing still is: LARAGON Since I left Windows a few years ago... I still miss it. It's so easy to use, super fast setup/installation, new sites are only one click away. AWESOME! Installing DDEV on Linux is quite a big task, reboots included. After the 3rd or 4th time it get's easier but still quite a bit of work. AND it's big. It takes quite a bit of space on your disk. A few gig at least. I remember my first DDEV setup and I swore to myself: NEVER EVER AGAIN! But then I tried my old setup with installing Apache, MySQL, PHP, and all the other stuff... it was quite humiliating and I installed DDEV again. Yet, never got it up and running on any Arch-based setup, which is fine, as I'm running Debian now. What I really enjoy is chaining commands (using aliases). Something like: ddev start && ddev launch && code . && exit from the terminal, wrapped in a FZF script or local .sh file... Nice! Which brings me to the benefits of DDEV... you can create your very own workflow with DDEV using aliases. A new PW instance or maybe even the other CMS some people are talking about... you can do quite a lot, still the docs are sometimes a bit hard to read and maybe too verbose (too much fluff in this case). My personal most loved features is that you can share your config to setup an identical environment with ease. .ddev/config.yaml for the win! Looking for and grabbing those setup prompts for DDEV to get the setup you need is just pure Gold! Some of you may remember I wasn't a fan of DDEV in the past. 😁

Ok... just thought about it again, maybe I was thinking about a ProcessWire 4.x release. That would be a massive one. Even bigger than the 3.x release.

To be abolute honest here... right now working with ProcessWire (Dev) on a recent hosting setup using my loved modules, feels a bit awkward. Besides one of my main hosters, all use PHP 8.1 as the default now - old instances not included, they still run 5.4+. I don't want to force anyone doing things they don't want to do right now, because it's not really/absolutely necessary. I'm totally fine with this. Latest PW Stable, PHP 7.4... total peace and harmony. My thought, see above, doesn't name a date or even a date range. Yet I somehow have the feeling that ProcessWire should somehow set a date for a minimal PHP 8.x version so everyone, especially module devs, have a roadmap/timeline for their modules. Even Core modules have issues with PW Dev on PHP 8.1 so I know that this isn't a thing we could or would see in the next 3-6 months. Still somehow developing with the latest and greatest PW/PHP seems a bit wonky (sometimes). To make it absolute clear here: Even though it sounds like I am complaining (which is fair, and true), it's more that I am worried. I have had 2 encounters now were people asked me why certain errors/warnings show up. They used a PHP 8.1 setup AND the latest PW DEV with some of our awesome modules as they were curious and wanted to try it, after I pushed them towards it. I did miss to say: Don't use PHP 8.1, which is a hype right now. Sorry! This is more a feeling, than a fact.

I wish I could help in one way or another but for now I just can say... it works... as expected. PW 3.0.220 - PHP 8.1 - DDEV What's your setup looking like: - Which PHP version? - Which environment? - DDEV, XAMP, MAMP, Laragon? Did you clear the compiled files and made a refresh after that? /adminurl/module/# (at the bottom) CLEAR COMPILED FILES

[See this post as a PUBLIC DRAFT for an upcoming post / aka thought dump] It's just a thought in my (confused) head right now... but shouldn't we, ProcessWire, the Community, and the ProcessWire Module Devs somehow focus/target a master release/version with PHP 8.1 as minimal version in the near future? Not only for ProcessWire itself but all modules. I'm not talking about ProcessWire 4.x but maybe 3.1.x or 3.2.x or something? Just to have a clear cut in some way. Almost everyone I talk to is looking for and talking about PHP 8.1. Right now there are so many fast moving parts in ProcessWire (CKEditor/TinyMCE, JS Updates, Core Modules split and moving to the database, and what not) itself and in terms of PHP 8.1 - either it works or it's somehow having issues, while everyone seems already working with it.

What exactly is your client looking for and where? In the backend or when the value is displayed on the website?

This doesn't sound good at all. Check access rights on folders and files please. Have a look here: https://processwire.com/docs/security/file-permissions/