Jump to content

wbmnfktr

Members
  • Posts

    1,873
  • Joined

  • Last visited

  • Days Won

    44

Everything posted by wbmnfktr

  1. 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
  2. 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/
  3. 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.
  4. 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.
  5. Are those different to the ones in the standalone VS Code extension?
  6. 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)
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. A bit weird and probably nothing to listen to while programming - still awesome.
  13. Mau P @ Academy - Los Angeles 2023
  14. 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.
  15. 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. 😁
  16. 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.
  17. 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.
  18. 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
  19. [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.
  20. What exactly is your client looking for and where? In the backend or when the value is displayed on the website?
  21. 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/
  22. Found this quite some time ago: https://upptime.js.org/ Might be a better fit or at least an option.
  23. I really enjoyed this post. Thanks @FireWire It almost feels like home. I almost have seen or experienced all of these issues and scenarios in one way or another. The never ending story of WP... of some kind. Yet... I have to admit that there are a lot of super experienced WP DEVs out there that know a lot about doing there stuff we all can learn from. They really challenge WordPress and not their knowledge. (Shoutout to MonkeyDev/Patrick!) Whenever I or WE (as in Muskaat) have to deal with a WP site, we make it totally clear to just fix that very issue and don't even bother or feel being responsible for any other existing or upcoming issue in that very site/project. ** Without that clear statement, "clients" wouldn't even think about paying us. But with that very clear statement, noone ever questioned us. Especially due to the fact that most of them had a very solid offer for one of our PW Setups/Projects, but decided otherwise. - Yet again... their decision. We are just the FIXERs for their decisions. Most of the time at least. We have seen very good WP projects that were stunning and almost perfect in execution. Yet... at some point there always was an issue. Most of the time, the WP DEV abandoned the project. In most cases we found another WP DEV to fix it but sometimes... we had to go another route. A total rebuild with PW, as we don't do WP/or most other CMS/Frameworks. In the last 3-4 years most of our offers were denied and answered with something like this: We knew we were too expensive with our offers - compared to similar agencies and solo-devs. We had to challenge those responses and learned from it over a lot of months and this was our answer most of the time: Sure, that's fine... and yes... they have to be. [BIG PAUSE] Don't worry they will do whatever they can for you and your project. You have our number. Let us know whenever we can help you out.** It paid out at the end. We could move most of the projects over to us and ProcessWire and went from there. We took full ownership of those projects and at least trippled everything from search impressions to clicks. But that's another story. 3 out 4 projects are now long-term partnerships.
  24. Just installed the previous version to get it up and running in my projects - finally. So... this is a very welcomed update or at least a nice surprise to work with. It's weird that I read through the whole docs today and made my notes just to see this update coming in. Be prepared to answer my stupid questions the next days. 😁
×
×
  • Create New...