LostKobrakai

PW-Moderators
  • Content count

    4,479
  • Joined

  • Last visited

  • Days Won

    92

LostKobrakai last won the day on June 20

LostKobrakai had the most liked content!

Community Reputation

4,287 Excellent

2 Followers

About LostKobrakai

  • Rank
    Excited Member
  • Birthday 11/29/1991

Contact Methods

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

Profile Information

  • Gender
    Male
  • Location
    Augsburg, Germany

Recent Profile Visitors

13,208 profile views
  1. With processwire not using foreign key relationships it does need custom hooks and/or logic to enable the structure I proposed. It's a bit more work to do, but also a lot more flexible than simply dumping all fields in the user template. Also users are by default stored under /access/users. Only with manually creating an alternative user template and enabling it in the config.php you could have users elsewhere in the tree.
  2. Yeah doing that manually not not really a good thing if you expect so many users.
  3. Generally I'd advice to keep the user template as minimal as possible. It's meant to authenticate users and hold basic infos applicable for all users, not to fulfil all your additional data needs, which can be related to an user. E.g. in your example I'd say a user might have a profile for avatar / social media or employee information for phone / address / department details. These can simply link back to the user they belong to. Having alternative user templates is possible in processwire, but it's limiting you to have just a single (more or less fixed) type for each user. As soon as your types of users can overlap that strategy is going to break down.
  4. They're just hidden on the frontend, but when saving processwire does make sure that fields, which would be hidden are not saved. Otherwise you'd get errors if hidden fields are required, but not filled.
  5. Did you try to look, what $params does give you?
  6. Valitron\Validator::addRule('notSubscribed', function($field, $value, array $params, array $fields) { return !isSubscribed($value, $params['listID'], wire('config')->mailchimp->apiKey) }, 'Everything you do is wrong. You fail.'); Like this somewhere before your validations?
  7. Yeah, but the forum does (need to) handle with lot's of user data. There it makes sense. On processwire.com I'd imagine besides a handful of people nobody is authenticated or otherwise handling any kind of non public data.
  8. Symlinks will surely work, but really if you're separating them in different sites, why couple them together via modules? I can see the appeal, but really it's a bit more initial work for more freedom later. Also multi site setups are rather rarely used, so I'm not sure if there will be much of a roadmap for the feature.
  9. The difference it that changing the field visibility is handled fully client side in javascript, whereas when it comes to saving the show_if/required_if selectors are validated on the server in php. So naturally having two implementations of the same might result in slightly different behaviour. With users and the roles field being quite restricted entities in processwire it's at least a bit understandable, that things might not work in all constellations.
  10. Isn't this just shifting the bottleneck from the single server's resources to the speed of accessing the single shared filesystem? I mean you've still a single server being hit for all your requests.
  11. Did you see that page? http://bulma.io/documentation/elements/content/
  12. I'm not sure this will help, but try the following: $pages->find("template=file, sort=-fileField.modified") Especially if you plan on adding pagination to the whole thing sorting at runtime will bite you in the ass.
  13. $coaches = $pages->get("/coaches/")->children($selector);
  14. How about that? https://processwire.com/api/ref/template/
  15. Yesterday I released 0.3.1 with the access migrations like described here: It does also include a fix to allow usage in multisite setups using $config->paths->site instead of hardcoding /site/….