Jump to content

LostKobrakai

PW-Moderators
  • Posts

    4,944
  • Joined

  • Last visited

  • Days Won

    100

LostKobrakai last won the day on January 24

LostKobrakai had the most liked content!

6 Followers

About LostKobrakai

  • Birthday 11/29/1991

Contact Methods

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

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

22,094 profile views

LostKobrakai's Achievements

Hero Member

Hero Member (6/6)

5.3k

Reputation

188

Community Answers

  1. If content is created in both dev and prod concurrently and meant to be merged then you're essentially maintaining a distributed system. There's a lot of knowledge around on how to deal with them, but all that doesn't make it a simpler problem and not having conflicts (or resolving them automatically) remains to be a hard problem. That's why the migrations module I created ages ago used migrations to captured the intent for change instead of trying to merge observed changes after the fact – the latter either comes with a lot of caveats or is impossible. The simplest solution for the specific problem discussed is the suggestion of @wbmnfktr. Use two separate systems for files created in dev and pushed to prod vs. the system for files created in prod, that way there cannot be conflicts in the first place.
  2. Looking at my commit log on the folder it seems I had made that edit manually as well. I'm certainly with you on the storage. In the end for our system it would've been much more useful for pages to be assigned/tagged a customer and have access matched by assigned customers for users instead of matching drole to individual pages.
  3. We're in the last steps of phasing out the project I was using it on. Most parts had been replaced years ago since we moved away from processwire with that project. The module's approach to access is nice, but iirc there were some bugs in the master implementation and we actually would've needed a bit more flexibility out of it (still needed code to create those dynamic roles). I'd still suggest it over expensive runtime access checks if it aligns to a projects access setup. We've been using it because our access was not only scoped by roles, but also by customers. So a manager would only have access to manager pages, which belonged to a customer assigned to that manager. Customers weren't static, but also defined by pages within the system. Things also weren't segmented into individual page trees, though iirc the modules for segmenting by page tree didn't exist at that time as well.
  4. Another example could be migrating an address stored in a textarea, which should be split into multiple dedicated text fields (street, postal, city, …). Or some set of fields on template A, which should be extracted/migrated to template B – creating new child pages wherever there are template A pages. Imagine pages having a single address, and now they need to be able to have multiple addresses.
  5. This sounds interesting. Though I wouldn't really call this file based config. It's not a single config, but rather migrations, which work off of a declarative config. Still wondering how this would deal with data though. Say I have a text field, which needs to be switched out with a pro multiplier while keeping the current text around as the content of one of the subfields. The above makes it seem like the prev. field and contents would just be deleted and the new one would just be empty.
  6. There are also some other alternatives besides matomo with plausible analytics or fathom analytics. I personally like those because they generally also do less. Most people don't actually need all the fancy advanced features anyways.
  7. I'd be curious how the other tools with file based config manage changes over time. My biggest problem with file based config (over file based migration) is that it'll only give you the current state you want things to be in, but no indication of which state the system is coming from and how to actually make data already in the system(db) be migrated to the new expected state. I'm not aware of declarative systems being able to handle that, which to me severly limits usefulness. It might be great in the beginning of a project, where you can scrap existing data, but won't work at all once old data needs to be maintained going forward.
  8. For redirects I suggest: $session->redirect($url, 307);
  9. The core could maintain a list of checksums for its own site profiles, which would restore security to prev. state even with downloads involved. For third party profiles there could be a warning about the tradeoffs involved.
  10. I‘m using https://www.inwx.de/ and am quite happy with them.
  11. Seems to be a misconfiguration on the webserver given it's trying to open /home/motatria/public_html/wire and in turn /home/motatria/public_html/wire/index.php as directory indexes are disabled. ProcessWire's entry point index.php is one folder up.
  12. Alternatively someone could build/generate a docset from the php sources for usage in dash or zeal. No stars required. https://zealdocs.org/ / https://kapeli.com/dash https://kapeli.com/docsets
  13. This should not really be a problem for timestamps like created_at though given they're not in the future. You'd still need to know the UTC datetime and the users timezone, but the offset should not change. A problem is storing a datetime today pointing to a day e.g. 10 years in the future. Within those 10 years the definition of timezones might change and what you though would be the offset in 10 years might not turn out to be the offset anymore.
  14. You can look at the utils here: https://github.com/chartjs/Chart.js/blob/master/docs/scripts/utils.js. Seems like there not really complex, but likely make documentation examples more terse.
  15. Generally I advice to keep formatting/parsing at the edges of any system. Input type number is basically the outermost edge by having the client deal with the normalization, as the client has the most knowledge about the user (locale, system settings, …). The visible input is formatted to the users settings, while the number submitted is normalized cleanly for computers to deal with. The next outer most layer in processwire would be the Inputfieldfield module. InputfieldText does handle text and doesn't claim to do anything else, while setting it to type number as you asserted might lack features. So the solution would be to create another Inputfield, which is aware of different means of parsing/formatting numbers – maybe even being aware of locales to not just guess the former. This could still render a text input, but handle all the details of locale aware number formatting and parsing.
×
×
  • Create New...