LostKobrakai

In my opinion "bestückt" is the better adjective because a page using a template doesn't automatically mean its fields are filled out.

You might need to disable the new(ish) function api. These are global functions and as the error shows you may not redefine those.

I was more concerned about the "in parallel" aspect, than anything else.

https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ This provides ways of dealing with this limitation, which don't involve replacing one problematic behaviour with another. Maybe one of those fit's your usecase?

$page->getUnformatted('myValue')->myMethod(); This should work.

I'd be curious if this is actually what you want though. I mean you can maybe ensure that your webserver doesn't handle requests for a given user in parallel, but if requests don't happen at the same time the user might still be working in multiple tabs on different parts of your website.

Personally I'd only do headless cms's with static sites. Where the static site generator pulls from the external cms for building its content. This is great because the cms is only concerned with providing data and the static site generator is concerned with rendering those into html.

This is where postgresql outshines mysql by far. It can do stemming and accent support for multiple languages out of the box, ranking, fuzzy search, … which are the things you found missing. Many people/resources seem to suggest not bothering with mysql for advanced full text search needs, but directly going to purpose built external technologies for that, while postgresql provides a stepping stone, before needing to go that route.

If you're dealing with multiple timezones I'd strongly suggest not involving the db in it. There are two types of datetimes: absolute time (times you want to compare with each other even across timezones) and wall time (11 o'clock stays 11 o'clock for your user). Because timezone defintions can potentially change for future datetimes it's not always as easy to keep both properties as one might think. If only the first one is important to you you should keep everything in UTC. If only the last one is important you could use a datetime in the timezone of the user, but it's rarely the case you don't compare timestamps or it doesn't become a requirement (e.g. for ordering). For past datetimes it's enough to store a utc timestamp and the timezone of the user to get to both the absolute time and the wall time as timezone defintions rarely change in retrospect. For future datetimes you'd need to make sure to save enough information so you can detect changes in the timezone definition when they happen. Then you or your user can decide if absolute time or wall time was meant to be consistent.

You could likely skip the "… that can integrate with PW" part and get similar answers, besides maybe less favoring of PHP based solutions. The only modern forum software I'd recommend today is discourse. It's modern, but doesn't try too hard to be "different". Everything else I had my hands on either feels/looks dated or is not there (yet)/will never be there in terms of being a forum.

I've heard from a few people in the last weeks, which seemed not to happy about by decision in regards to this module and especially the suggestion of RockMigrations as an alternative. Therefore I'll leave a few more thought. The module has been in it's current state for years. The last commit from my side was from Juli 2017. Just like the module continued to work till today it'll likely do in the future. There might be things to change with new PHP versions or PW versions – but maintaining working condition should be a fairly simple job. Given that I don't have any active projects anymore using the module (to the most part even for processwire in general) I personally can't and won't deal with keeping the module maintained. My suggestion for supporting RockMigration was mostly based on the fact that it's way more actively maintained and I feel it's better to group efforts behind a single project – especially given the processwire community being on the smaller end – but if RockMigration doesn't work for someone and this module does, feel free to use it. I'd be happy for anyone to pick this up and maintain it going forward, it just won't be me. /cc @Sascha Nos @elabx

To be fair ProCache isn't really what one commonly understands by "static page". You cannot easily take what ProCache generates and e.g. publish it to GitHub pages or netlify. The cache is also generated on actual requests to a certain page. There's no command to "generate all pages". So you'll likely still need to run the full CMS on a webhosting doing php and having a mysql db. You just won't hit the php runtime/db for requests, which hit the cache. Therefore you can take a bunch more traffic on the same machine. For actual static pages (html/js/css as output) I really like eleventy. It's really flexible and if you like processwire for the authoring experience you could e.g. render a json document out of processwire, which you feed into eleventy as data source.

I'm sure it's the less used path, but a CLI is useful for anybody automating deployments either using some kind of CI/CD or manually called scripts. The goal of my migrations module was to result in reproducable db state, so automation is possible. If migrations can be run arbitrary times it's not going to do that – e.g. a field created and later deleted is not the same as a field deleted and later created. Therefore migrations have a fixed order (by timestamp) and a db table keeps knowledge about which migrations were already applied before.

I just installed the module and besides initially having the wrong profile (I usually go with Blank) it works great. I'm wondering though if there is support for product variants like sizes?

If you don't make (enough) money by providing hosting I'd not take on that burden. Providing hosting can be business, but it depends on the bottom line as well as your enjoyment out of doing that job. If neither or both are missing it's most likely not worthwhile.

As hinted in the topic on RockMigrations I'll deprecate my module in favor of it. I've added noted to github and this topic:

That's good to hear. I've never actually tried out RockMigrations, so I wasn't really sure if functionality matches up like I expected it to do. Quite simple: I no longer feel it's a great fit for the stuff I'm developing, which is custom web applications opposed to websites. I've not only switched framework, but also language to using elixir and the phoenix framework for most of my work. I still use processwire for some websites, but they change rarely so they're not really the ones invoking changes to my modules.

I'm actually wondering if I should deprecate my migrations module in favor of yours. I'm hardly using processwire professionally anymore and while my migrations module is stable and will likely continue to work I won't do any considerable updates anymore. To me it feels your module does everything my module does and a bunch of things more besides the fact you're still actively invested in it. Do you think that's a fair statement?

At best you do that as a compile step. I hardly deploy any content anymore, where I don't have a js/css buildstep or even CI. Those are great places to do such things once per "change" of the running code.

Sure, but this is imo best done by appending e.g. the md5 hash of the file contents for cache busting. This one will actually only change if the css file itself changed.

Nowadays open dev tools and disable the cache in there. No need for hacky cache busting on each request.

It's probably doable, but I see 2 potential problems for it. The first one is missing structure. ProcessWire is super flexible, which means you won't have any guidelines how to structure whatever you're building in a way that your customers will be happy with it. For customers this also means more overhead in trying to apply a certain bought solution, as each might work differently. The other part is market size. Themeforest and people on the platform do make their money by volume. Wordpress and HTML Templates are great for volume sales. ProcessWire doesn't have that kind of adoption numbers. This might be a classical chicken/egg problem in that not having things on themeforest might keep adoption low, but if you're looking to make money (in a reasonable timeframe) I'm not sure concentrating on ProcessWire in a setting like Themeforest is the best bet.

Device.js is 6 years old, which for a topic like media queries is ages ago. Generally I feel like if you really need to alter markup, and not just styles, for different devices use client side templating. Those cases should imo be a small minority, so it should concern the least amount/local to the problem code of your codebase possible. Having different domains is however like a sledgehammer everything on the server suddenly knows about. Generally media queries based on device size / touch capabilities won‘t give you a great picture anyways with today's devices. Take microsofts surface or ipad pros, which have resolutions bigger than some older laptops, touch and mouse support as well as alternatives like the apple pencil. There are more useful media queries in the pipeline about hover capabilities or coarseness of the pointer - finger vs. pencil. I wouldn‘t want to involve this complexity on the server side.

Just to bring another point in favor of that: The limits of precision for floats showing for bigger numbers. > new RockPrice(11111111111111.505, 10, 2) object(RockPrice)#1 (5) { ["tax"]=> float(10) ["vat"]=> float(1111111111111.1) ["net"]=> float(11111111111112) ["gross"]=> float(12222222222223) ["digits"]=> int(2) }

I can fully understand that. I just wanted to give the full picture. How much of it matters to your case is nothing I can decide ?