LostKobrakai

I don't think we can use grid for global layout soon. But for single components it can be just as useful in places and it doesn't seem like to much of a hassle to have less sophisticated looking fallbacks for those smaller usecases.

@abdus Handling modules is realm of the superuser as one can potentially break lots of things there. If you need non-superusers to edit module settings I'd create a custom process module, which does handle changing the module config in a more secure way with validation of changes and alike.

The superuser is like it's names suggests super. It's like the admin user you get in each other system out there. There aren't any access restrictions on that role. It's meant for the people developing the website and should not be used for content-creators. Also it wouldn't make much sense to add access restrictions to an user, which most likely has access to any configuration files as well as the database behind the website.

I've just merged the changes of @Macrura.

Here's a primer on what hooks are and how to use them: https://processwire.com/api/hooks/. They're essentially a way to add custom functionality within processwire's workflows.

Just a word of caution. Do not use this in high traffic pages, because it holds a race condition, where people might be assigned the same number.

You could build some custom logic into templates/admin.php to switch the language to something else temporarily. But by default switching languages for users does use one and the same field to store that switch. So you'd probably need to add another field to the user to store something like a "backend_language".

When we're already at chromium based browsers: Opera is also based on it (actually for quite a while by now) and it's been the first time I stayed with it longer than 2 or 3 weeks.

There's $template->altFilename which I think is relative to the templates folder.

@ryan I'm curious did you read my ramblings in the wishlist topic (and elsewhere when the topic poped up)?

@guy You code will break for urlSegments which list multiple segments in one line ("some/subsegment") as well as for regex segments ("regex:[0-9]{4,5}") And there's no good way to detect a valid url in processwire without doing a http request or faking one by manually running ProcessPageView. All the logic for finding the page one is on and the validity of urlSegments and so on is hidden inside that module and there's hardly a way to reuse if for custom purposes.

I've done some websites with fractal directly using the style guide templates (twig) from within processwire. I've written a (german) medium post about it: https://medium.com/webdevs/living-styleguide-mit-fractal-und-processwire-e900f05e0b79 But I'm sure with recent updates to fractal stuff might no longer work exactly as explained. Overall it's been a nice experience to try it and for larger organisations / projects I'd expect it to make more sense. Our projects were kinda smallish and we're two people, so the overhead seemed to be a lot. As all templates came from the style guide I had to have all different versions of pages in it, so it's really easy to communicate with people, as you can view all of them in the style guide without actually having the real website in that state or getting it there locally (the website had different stages for an event registration).

The 3.x API reference pages are build from the docblocks in the core files. So it's already on github and updateable via PRs.

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.

Yeah doing that manually not not really a good thing if you expect so many users.

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.

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.

Did you try to look, what $params does give you?

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?

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.

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.

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.

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.

Did you see that page? http://bulma.io/documentation/elements/content/

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.