LostKobrakai

I've tried out mollie a few weeks back and they have their internal timeouts. Unless they're to long for your usecase I'd consider mirroring those of your payment provider.

This is a classical distributed systems problem: Your options are idempotency, reserving limited resources early and implementing compensation actions (e.g. compensating for missed payments by freeing the resource again). At some point it might even be useful to involve humans instead of trying to cater for each error case in code. The other part as @Jan Romero pointed out: Give whatever you sell identities. Instead of decrementing number of event tickets available create 100 tickets upfront and link them to orders. A ticket not linked is a ticket available. This is a more natural and easy to understand way of dealing with the domain. In the real world you also first print X tickets before they can be sold in retail. Same should apply to your spaces. Take that from someone having build a system similar to like you intended in a not so critical space (a handful of tickets more are not critical) and while not having completely regretted it I could soon see the problems of it.

You might also want to look at the session fingerprinting.

mod_security is known do cause all manner of problems with various systems. One can get them under control, but from my experience most people just disable it.

There has been support for paginated fieldtypes in processwire for quite a while, but afaik to this day the pro module FieldtypeTable is the only one using it. It's possible to build e.g. a page based paginated fieldtype, but nobody did that yet.

I moved to plausible analytics starting this year. Even a cookie-less option for google analytics might not solve the issue given google will likely continue to use the tracked data for own purposes, which affects the classification by the gdpr beyond just the tech. boundries of cookies.

The HTML5 number input should handle that already. For formatting for output I'd suggest looking at NumberFormatter of php / the intl extension. Having worked with a cldr based library elsewhere extensively I can suggest everyone dealing with locales to use a library for all those differences instead of building one-of solutions.

Since google bought .dev it's supposed to run with HSTS autoenabled. It's no longer a great option for local development and HSTS can be a pain for hosted development pages.

Your points about this are all completely fair. It's up to you to integrate or reject the changes a PR does. Currently the latter however does not happen in a manner visible to the creator of the PR or anyone else looking at the PR. So they just stack up looking like they were never looked at. If you consider something not possible to be added (or even not possible in the near future) everyone is better off if the PR would be closed with a short note of the reasoning. PRs do not age well and it's better to close them than letting them sit until no longer mergeable. The closed PRs (and issues) are still searchable, so if people to their due diligence they'll see that things were rejected before, find related discussion if attached, …. If you're not happy with the code for a given change you can also help people come to a version you're happy with maintaining without needing to go code it yourself. This does even work for issues. One of the most encouraging responses to issues I know from other OSS projects is "Sounds good. PR welcome.". I rarely see that as a response to bigger feature requests, but on smaller incremental things making parts of the project better it's a good way to move the burden of actually fixing something off of the maintainer themself. If a PR is not of that kind it's totally fair to close it with something like "This is to big a change and needs upfront discussion before consideration.". You don't need to take the time of reviewing PRs in depth, when you already know you'll not merge from just the title/description/amount of changes/…. So in conclusion: Without a response from your side a open PR is dead weight in the context of the community helping you improve processwire. Someone did some work and now it's stuck. Even if the response is negative it'll give anyone involved context either to adjust and be fine with things not being added or next steps to get things integrated either by starting a needed discussion, changing the code or implementation or whatever else needs to be done before it could be merged. Given the fact PRs don't age well I also feel response should be reasonably timely – even if the merge actually happens at a later time. Take a year and the PR creator might have moved on or worked around it, the underlying code changed in the meantime so the PR is no longer easily mergeable, but the issue fixed by the PR might still be present. I know this well given I have two open PRs for processwire from 2017 – one small fix, one not as small feature. I hardly use processwire anymore by now.

There is a setting for page fields to allow for pages to be added through it. Iirc in core inputfields this is a completely separate input below the actual page selection. This needs to be enabled for this module to be able to add new pages, as it's using the built in input, but just hides it and allows you to add new pages inline.

The module piggy-backs on the core functionality of adding new pages on demand. Could you make sure that it works when using core inputfields?

Exactly that; when visiting the admin page, which should show the updates. Not sure where this one is coming from.

What exactly would I need to be looking for? I've the problem of the memory leak as well.

Selectors are only for fetching pages, not field values (even though tech. the field value here is pages). You can use this: $first_three = $services->get("service_box")->slice(0, 3);

Sqlite might be a possibility, given it has pdo support and is still a sql database and even that is likely a lot of work for making the things currently expecting mysql as a db flexible. Going away from sql would mean needing to replace all the query building facilities, which basically hits almost all parts of processwire – I'd estimate that as at least a rewrite of half of processwire. And that's just the implementation. For actually making this a reality it would need extensive testing and ongoing maintenance efforts, both of which I doubt will happen – at least without any appropriate financial incentives.

find does return a pagearray, not a single page. You need findOne or get.

Try the following, which will ensure you get an timestamp and not a formatted date string. $item->getUnformatted('date_start');

This will only work however if you're not further processing the media (images). If you're using processwire's image api for creating variants, then they shouldn't compress things before uploading, as tightly compressed files tend to produce heavier variants than less optimized ones.

This by itself is already a problem. Given the gdpr privacy laws it's reasonable to justify why IPs need to be processed for actually handling the http request, but storing it (especially indefinitely) is a completely different ballpark. IPs can be used to identify people and therefore should be treated like that. It's not simple nor accessible to the everyday person, but if you have access to an ISPs records you can trace back an IP at a certain time to a certain household and potentially a single person.

The biggest thing to keep in mind is that mobile OSes don't just run any programming language. iOS runs swift, android runs java(/kotlin). Then there are a few projects bringing external languages/tooling onto those platforms like react native (js), flutter (dart), …. This is quite a different world to web development. Then for web technology you can also look at progressive web apps, which are less powerful than native apps, but can serve similar purposes and can be developed quite a bit easier. ProcessWire or Laravel are just one (likely the simplest) piece of the puzzle by being one of many ways to have a server side backend – you won't get the app itself from them. Meteor is a bigger piece of the puzzle as it's client and backend at the same time, but truthfully I wouldn't suggest meteor nowadays. Its ideas were ahead of the time and it never really took off. Today it lives on mostly on the sidelines. At the moment I feel flutter or react native based apps are the best way to build an app, if it's meant to be for production use. For the backend choose your favorite flavor of server side tooling. Likely something graphql, which makes it easy to interact with from the apps perspective. All this however is nothing you learn in a few days and be able to produce an app. I feel not even webdev can be learned that fast anymore.

I'm not sure about the word "template", but I for sure have a few such words by myself as well. And I can't really blame my native language given I'm likely writing more english text than german ones at least on a physical keyword. At least for mac's there's a way to have aliases, which automatically expand to different text. There might be similar capabilities on windows as well. Maybe that's an option.

Afaik there's no such option, but ryan does allow for refunds.

Another idea: You could generate permutations in advance from like an array [1, 2, 3, 4, 5, 6, 7, 8, …], write them each in a file per line. Then stream the file and use the numbers in each line to access the addon at index X. It's still a lot to iterate and creating those files (needs one per number of addons) is a task at raw computing power, but at least the json will probably be created quicker.

It doesn't seem like addons also get a multiplier applied. Can you not just have the addons be "additional products" then? Edit: To save on raw memory you can also calculate the combinations just by id, while calculating the price one object at a time. Currently you create an object for each permutation.

Now begins the waiting for all those "we''d like to do X" features to become actually stable ?