Jump to content

LostKobrakai

PW-Moderators
  • Content Count

    4,830
  • Joined

  • Last visited

  • Days Won

    98

LostKobrakai last won the day on February 19

LostKobrakai had the most liked content!

Community Reputation

5,002 Excellent

6 Followers

About LostKobrakai

  • Rank
    Hero Member
  • Birthday 11/29/1991

Contact Methods

  • Website URL
    http://www.kobrakai.de

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

17,892 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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, …)
  8. This is less a question for how processwire works and more about how jquery datepicker works: https://jqueryui.com/datepicker/#localization
  9. 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.
  10. 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.
  11. > 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...