Jump to content

LostKobrakai

PW-Moderators
  • Content Count

    4,839
  • Joined

  • Last visited

  • Days Won

    98

Everything posted by LostKobrakai

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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).
  8. I'd look into unicode's cldr database and something like e.g. https://punic.github.io/
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. This sets the format for the input of dates/times (dateformat in the datepicker API), but it does not change the language of the datepicker UI, because this happens by including or not including those translation scripts you mentioned above. They basically set the datepicker to be in a certain language and don't just "make the translations available". Technically you can make jquery datepicker switch language at runtime, but I guess not including translations when not needed is the simpler solution. Edit: As to why the core itself doesn't handle including the correct files: ProcessWire doesn't have means of identifying languages. You can name your languages however you want. So it cannot map languages created by the user to something like the path for the datepicker translation, because it doesn't know a certain language is supposed to be e.g. german in the first place.
  15. That's what I was thinking about as well. Theming I'd divide up in 3 parts, which need to be handled: Getting data out of the persistance layer in a format, which is well defined to theme developers. Without knowing the data upfront I'm not sure how one would build a UI for it. Ways for theme code to format that data into markup snippets. A flexible way to compose those snippets into a whole page. (Having a way to handle http inputs (form submissions, get parameters, …)
  16. This is less a question for how processwire works and more about how jquery datepicker works: https://jqueryui.com/datepicker/#localization
  17. I guess this is a bit of a chicken and egg problem. The admin in processwire is hardly anything special based on what the core knows about it. It's a bunch of pages, which just happens to be tightly access controlled and forwarding their handling to process modules instead of rendering templates. So before knowing the page you're on there's not really a good way to know if the request is going to serve an "admin page" or not. To query the current page a lot of things already need to be started, and I guess you want to hook into those before any pages are queried, at best by already knowing the context, which is not going to work. A good example is the function you've shown in your initial post. It's a good heuristic for determining if the user is in the admin, but also not bullet prove, as there can be normal pages as children of $this->config->adminRootPageID as well. It might rarely happen, but it's possible. The only way to be sure is actually having $page queried.
  18. That's not really true. Ryan's Dynamic Roles module does add additional sql clauses to ensure dynamic roles are fully resolved at the database level. Sadly is the module is not very well maintained and it could also be build a bit more flexible (e.g. matching on calculated values instead of just "membership"), but it is possible. This to me sounds like a very hacky workaround. You initially said you don't want to bloat the system with hooks. Blacklisting IDs and filtering them at runtime is very likely to be way worse for performance than a handful or two more hooks.
  19. > If setting the cookie fails (like due to prior output) ProcessWire remembers it in the session instead, and sets it the response to the next web request (before any output). I‘m wondering if raising an error would actually be the better option. Letting a cookie creation succeed, but not actually creating one might lead to hard to understand bugs. At least the return value should indicate that creation of the cookie was delayed to the next request, even though I can‘t imagine cases where I would want that type of behaviour.
  20. I really feel this is a good thing that it's still only working that way. I get that there's no great way to discover modules, but I also feel that "discovering modules" is a totally different tasks to "managing modules on the system", which is what the current modules section in processwire is about. The ability to install just by name from the modules directory is imho a nice to have convenience and not an unfinished start of integrating the modules directory as the source for modules. The modules directory is just one source for modules, possibly the biggest at least for open sourced modules, but not the only one. This is not to say though that a module filling the gap of "discovering modules" isn't useful and what you created seems like a very nice way to browse the directory and move a module from being listed there to actually being downloaded/installed. I'd personally wouldn't like to see the current module section replaced though. This hint's at the reasons for the above. Browsing the modules directory is great with a cards view. Maintaining installed modules is a totally different task. It needs modules to be quickly scanable - table layouts are way better at that -, it needs to highlight different data - a version is more important than a lengthy description of what the module does, or how many hearts it got - and I'll also hardly switch rapidly between browsing and maintenance so it doesn't need to be co-located in the interface. That part I'd like to see in the core (a bit depending on how it's implemented though). This is an improvement to the "maintaining modules" part of having installed modules, but rather nice to have when browsing modules. To summarise: I really like the problems you're tackling with your module, but personally I'd like to see the efforts split up. The part about "discovery" is great, but certainly not essential to processwire and should in my opinion be either not in the core or at least not installed by default. The part about better maintenance of modules and maybe touching up the UX of the current modules section by lessening the clicks to handle certain usecases is something anyone would benefit from.
  21. If you have proper auditing tools in place then any modifications should be recorded. The other part is authentication/authorization. If you can verify that nobody can modify a certain record you're fine. Those things get tricky though for the people, who are responsible for setting up those systems, because they often also have the ability to circumvent them. That's the place where you want to keep access very restricted to a small set of people, still enable logs where possible and start using policies, which "tell" those people what they're allowed to do and what they're not allowed to do. As soon as you cannot (tech.) prove something wasn't modified you should at least be able to prove that you had other measures, which disallowed modification and to know exactly who had the ability to change things in a non-trackable fashion. There's no fool prove way to this, unless you give up control completely to a third party, and there are always going to be parts in your setup, which are best effort instead of watertight. From my understanding a good part of an evaluation by authorities will include not just technical checks, but also softer targets like proper training for personnel, written evaluations and documentation.
  22. Please don‘t. Brunch is no longer maintained since over a year iirc and even before it didn‘t really hit a place where is was working well for more than basic setups.
  23. ProcessWire protects what it knows it needs to protect. Blocking everything can be just as annoying especially on e.g. shared hosting where there might be some wordpress site in some subfolder. Or some new favicon file for some new mobile OS to be added to the root. There‘s even a xml file for MS in the mix already. So I feel like e.g. having a list of known sensitive files like .pem/.crt/... blocked would be a nice addition. .phpc is afaik also a often used extension for php. But I‘d not support blocking things beyond that.
  24. Memorizing classes will always be needed. If you take a pre-build framework or your own classes. The big productivity improvement is not in writing CSS using @apply and tailwind classes, but in writing just html and adding tailwind classes directly to the markup. So you need the backing css to already exist. Once you have to switch to a css file you're already loosing on the productivity gains. If you're using properly separated templates there might even be no need to later move the utilities to custom classes and `@apply` as everything's already in one place - the template of a component. Having the utilities out of the box is exactly the selling point of tailwind. Sass/less don't give you classes you can put in your markup - they're pre-processors. It also doesn't want to be a contender to e.g. uikit or bootstrap because they require so much work to be bent to custom design. Building your own components is expected, as custom design most often does require that anyways. There's however some work on a component library being done, which is build on top of tailwinds utility classes; and which will probably be easier to customize than e.g. bootstrap. If you have your own custom utilities library tailwind probably won't be of much benefit. If not however it' a great way to get started quickly on a existing, well documented, well adopted framework. Tailwind by default comes with 9 shades of each color, where afaik 4 are accessable colors on black and 5 are accessable on white background. And you can still edit them, those are just defaults. The message is not "you should not use more than (those) x colors/shades". The message is that a well managed design system must use a fixed set of colors, which is different to each person on the team just adding a new shade each and every time they add something to their codebase. The latter most often being the reason for the exploding number in color or text-size variations. It's about consistency and less about absolute numbers. Imho the need for all those customization variables of frameworks like uikit/bootstrap and the lock-in to a certain preprocessor already show how "inflexible" those solutions really are. I've not yet used any of those frameworks, where I didn't hit a brick wall at some point trying to skin a component to a custom design, because some aspect of a component wasn't customizable (either markup expectations or missing a "configuration variable"). To me tailwind css is neither an alternative to writing css, as the building blocks are way more cohesive and well rounded as well as "higher level" than css 1 – but also not for frameworks, which often impose quite an amount of markup constraints and understandably a certain kind of style, which can be problematic when implementing a custom design. [1] Take for example .truncate. There's no single css rule for truncating text properly. It's overflow: hidden; text-overflow: ellipsis; white-space: nowrap Same for e.g. .rounded-t. It applied rounded borders to both top edges, instead of css, which requires you to set it for each edge explicitly. This is more in line in how a designer would think about a design than how css needs it to be implemented. Nobody will say "make the top left and top right edge rounded". People say "make the top edges round" or "truncate that line".
×
×
  • Create New...