Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


LostKobrakai last won the day on February 19 2019

LostKobrakai had the most liked content!

Community Reputation

5,015 Excellent


About LostKobrakai

  • Rank
    Hero Member
  • Birthday 11/29/1991

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Munich, Germany

Recent Profile Visitors

18,273 profile views
  1. 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).
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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.
  7. 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.
  8. 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).
  9. I'd look into unicode's cldr database and something like e.g. https://punic.github.io/
  10. 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.
  11. LostKobrakai

    HTTP/2 Push

    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.
  12. 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.
  13. LostKobrakai

    HTTP/2 Push

    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.
  14. Usually I'd say the best approach if you need multiple formats is storing the information in a canonial format and using different formatters, which can convert the canonical format the the various output formats you have. Kinda like e.g. datetimes are stored as unix timestamp, but that's hardly ever the output format.
  • Create New...