LostKobrakai

The problem is less so multiple tabs and more so spotty internet and detecting people leaving. The server cannot know if people disconnected due to whatever reason unless being constantly in communication with them(e.g. a heartbeat msg) and using timeouts to mark someone as offline once responses are late or missing. This get‘s even trickier with multiple servers as people could have connection to one of the servers but not the others. So someone is only offline of there‘s no connection to non of the servers. I‘m not sure if this is a problem for your usecase, but that‘s what‘s tricky about even just basic availability lists of users. There are solutions for such problems, but personally I‘d not even go with php to solve them, so it‘s nothing pw can help you with greatly.

Personally I don't feel UI necessarily needs automated tests, but business logic certainly does. E.g. currently this happens: > var_dump(new RockPrice(1000, 3.7, 0)); object(RockPrice)#1 (4) { ["tax"]=> float(4) ["vat"]=> float(40) ["net"]=> float(1000) ["gross"]=> float(1037) } This is because the tax is rounded to the number of decimals used for the net/gross value, but it's not consistantly applied in rounded form. This makes the invariant of net + vat = gross break. I'm not sure if it makes sense to round the tax to the same decimal places than net/gross. Generally I'd opt for https://github.com/moneyphp/money for representing money in php – especially given the fact I had code similar to yours in a codebase of mine. The library has been around for quite some time and includes everything to properly deal with money.

It's not only the servers by themselves, but also all the network parts between anyone of us and those servers.

That sounds great. I'm mostly using elixir nowadays and they have a language server implementation, as most editors don't bother implementing it by default.

I'll certainly take a look at it once it's in beta, but I'm wondering if you can tell us something about which languages it actually supports and if it uses something like language server protocol? I used coda ages ago and I liked their batteries included approach at the time.

Basically any calendar application. If I have an appointment in a year at 10 o'clock, then I want to be reminded for it being at 10 o'clock. People usually don't care about the absolute time in such cases. Any change in wall time would be considered incorrect. On the other hand you're correct. If e.g. a job is supposed to run a fixed amount of time then a change in timezone definition shouldn't make it run longer.

So the key information here is that the offsets of timezones are not fixed for eternity. There are databases you can download to your OS or e.g. from groups like IANA, which hold information about which offset a certain timezone was exposed to at which period of time. And those databases are updated about a handful of times a year (but not each time for actual new rulings). A good example for actual changes is the EU, which is currently starting the process of migrating away from switching to/from DST. Generally you're mostly fine for past datetimes, but the farther you're in the future the more likely it becomes the offset you expect the timezone to have at the time could change until that time. If you convert 12.12.2030 10:00 for Europe/Berlin to 12.12.2030 9:00 UTC with the current offset of +1 in the winter and we go forward 10 years it's not clear if you get back 12.12.2030 10:00 for Europe/Berlin. The EU's efforts to remove DST might have been fruitful and Europe/Berlin is now at +2 offset all year (all year DST). So you take the db value of 12.12.2030 9:00 UTC, you add the offset for Europe/Berlin, which then is +2 and you get 12.12.2030 11:00 for Europe/Berlin. The UTC datetime was preserved, but the "wall time" wasn't – wall time being the time I see on the clock here in my office. You might be an hour late to some important appointment. You can ignore all the above if you never convert between timezones, which as far as I can see, is what processwire is doing. 12.12.2030 10:00 for Europe/Berlin will still be 12.12.2030 10:00 for Europe/Berlin when read from the db in 10 years. Essentially the wall time is preserved. This comes at the expense of absolute distance of time between two datetimes being subject to change and not being able to have absolute ordering for dates of different timezones. The latter is not a problem if the whole system just uses one timezone. This is why I said it's important to know what you care for. The absolute time passing by until a datetime or the actual time on the wall on a certain day. If you want UTC timestamps in your db, but not give up preserving the correct walltime you'll need to store more information in the db besides the utc timestamp to be able to react to changes like I described.

There's one more problem. While the UTC time stays the same in the absolute term the wall time shown to the user might change. Say today someone enters a date in the future at 11 o'clock their timezone. At midnight an OS updates happen and a new timezone db is installed. The next day the time might be 10 o'clock that day. For dates - especially in the future - you'll need to be aware what matters to your users. Walltime or absolute time (UTC). Because the difference (the utc and std offset) are subject to change. If you want to compare datetimes in the db though all datetimes all need to be in the same timezone (or really UTC), so if that's a need it gets complex quickly because you need to store timezone and offset at time of writing to the db as well, besides the UTC timestamp. This is the only way to later come back to the intended wall time and being able to detect changes in timezone definition, which might result in a different walltime.

Python has one big advantage over PHP, which people might or might not care about: It‘s widely used for devops tooling because it‘s preinstalled on so many systems and it‘s growing super fast in the space of ML/AI/Science based computing because of it‘s bindings to fast low level C code while still writing python on top. If you care about those things or you want to do them as well, but not introduce a mix of technology, then sure python is a great solution. If not I don‘t see any reason to switch from whatever one is using right now.

Personally I‘d first look into using an existing solution for gathering the data (I‘ve had good experience with https://feed2go.com/de/) and just create a way to bring back data into existing systems later. Webapps have the problem that their storage while available at times is not ensured to stick around. If e.g. the device disk space runs low it might be cleared out. Also you‘re already in the realms of a fully client side app, so you could just embrace it.

The biggest hurdle of timezones is actually in handling "the future". Timezone rules are in constant fluctuation (be it error corrections or actual changes the IANA timezone database changes a few times a year: https://www.iana.org/time-zones). One prominent example is the EU right now, where DST was ruled to be eliminated in the near future giving each country the option to choose if they want to stay on DST or non-DST offset. Therefore to store a point in time (in the future) you at best store not just a datetime/timestamp, but a timestamp as well as the source timezone and used offset. This allows you to detect if the offset of a timezone did change between the time is was stored to the db until the time of retrieval. Otherwise changes in timezone definition might lead to incorrect results (someone being at a place at 11:00 when the time was supposed to be 10:00 wall time). This blog has a few posts on the topic, even if they're not in php: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html Edit: You can ignore changes in timezone definition by storing datetimes in their source timezone, but this won't let you easily compare multiple values in the db. I've some more interesting things on the topic to share. If you're working with intervals I highly suggest using Allen's Interval Algebra as well as watch this talk by Eric Evans:

The session cookie is unique to a browser session, and seldom used without you holding more information about the user, which by my impression does fall in the definition of personal data how gdpr defines it: https://gdpr-info.eu/art-4-gdpr/ But as I said the gdpr doesn‘t explicitly demand banners. It demands that users are informed about the usage of the data (privacy documents).

The GDPR doesn't actually handle cookies specifically. GDPR is about processing personal data. A cookie is processed by a webserver when a user accesses your website, so GDPR is applicable IF there is personal data involved in regards to the cookie. Even a simple session cookie is personal data, because it identifies a certain browser session, which in turn likely identifies a person. There are a few things GDPR demands you to provide to users in such a case, like what the data is used for (Art. 13/14) and it needs to have a legitimate reason (Art. 6) for you to be allowed to do so. This is even more complex if it's not a cookie set by your website, but by a third party. There it's the shared responsibility between your and the third party that everything is handled correctly. This is usually done with DPA (data processing agreement) which is a binding contract where both parties essentially guarantee each other GDPR compliance. The GDPR gives users the right to deny consent wherever you cannot use Art. 6 1.f) as legitimate reason. Therefore cookie-banners with the option to not have certain cookies set. The GDPR also says you may not auto opt people into giving consent, therefore the default for optional cookies should be unset. Besides the GDPR there's afaik a law in Germany for cookies specifically, which has been the kinda predecessor for the long overdue EU wide ePrivacy directive. I'm not as well versed with this one. It was essentially the law, which started all the cookie banner stuff.

Most of the stuff in the .htaccess is actually not needed to run processwire, but to prevent access to places nobody should snoop around. This only becomes a problem though if there is indeed a file in such a location, which would be directly accessed. In common usage those things rarely pop up, because who tries to read e.g. /site/config.php or even non php files of the installation.

Isn't that why there's getConfig and saveConfig now?

Why do you need to post values, which are no longer editable though? Should this not work just fine with the field disabled / not rendered as inoutfield?

The downside would be the need to ship a list of languages/iso codes with the processwire core. I guess with weekly releases it's not to much of a pain though to require a fresh release once there's a change in that list.

First of all ISO 3166 is for countries, not languages – there are countries like switzerland, which has 4 official languages. ISO 639 is what we would need. But ProcessWire doesn't care about that. You could be needing Globish, which doesn't have an iso code. So the iso code should always be optional anyways. This difficulty is exactly why I made my PR not rely on an automatic mapping, but simply let users decide which translation to import into which language of the system. Once processwire might add an field for iso codes to the languages template it's an easy addition to detect matching codes and suggest imports to the user automatically.

It is. You cannot be sure if default is english or not, but even less for the rest, where you don't know anything in advance about the name. What your module can do though is adding the required field into the template for languages. Edit: More related on the general idea of multi language modules and possibly less your usecase: https://github.com/processwire/processwire/pull/52 This PR would allow modules to ship with translation files, which any user can then manually import/map into their language setup.

Languages in PW are just pages. So you can always add fields to e.g. store iso codes in. There's nothing in processwire core, which would be helpful in identifying languages otherwise, as they just use user provided titles (and default).

I'd look into unicode's cldr database and something like e.g. https://punic.github.io/

This is really the problem: the fieldtypes/inputfields having no support for pagination. I hit that on a project of mine, where users are linked to tickets. Given that the event in question does attract up to around 10k users registering I needed to hide the inputfield completely, because even just showing the value uneditable would load all the users when showing the ticket.

Not only the admin. That's part of processwires bootstraping and applies to any request served by processwire. This applies to (user-)data shown, but not to more or less static resources like scripts or static images of the admin / other modules.

I'd strongly suggest that as well. A telephone number is not a "number" in the mathematical sense. You'll not do arithmetic on them, leading zeros are not optional, even though it's comprised mostly of digits there might be characters as well, …. Telephone numbers are actually identifiers and those are best stored in text or more specialized columns.

I know phoenix - the elixir framework I use nowadays - removed it's high level helpers for server push before it's last release, because something about the caching of pushed assets wasn't up to what they wanted it to be: https://github.com/phoenixframework/phoenix/issues/2875. I'm not sure if the situation has improved since then. I'm not sure how processwire would interact with http2 though, as most often php doesn't deal with the http layer at all. The webserver in front does pass data onward using fastcgi or whatever mod_php does.