LostKobrakai

If you don't need to worry about browser support then you should take a look at the newly available css grids.

There's also elastic search. Also I would advice against lunrjs if your content is not english. At least for german texts the default stopwords/stemmer combo didn't work out very well.

Nothing. The users page is a lister with pagination and the quick access navigation does at some point switch to showing just the available user roles and the number of assigned users for each one instead of all the available users.

Ok, it might not have been clear enough, but my statement still stands true: Removing that config line won't change any existing database tables or the database charset itself. So if someone does have that error without trying to add something new your tip won't help. Adding a field on the other hand does create at least one new table, where pw does again determine by that line which engine it's supposed to use with that new table and this might error as well.

The most flexible version would probably be a monolog (or compatible) implementation, just because how ubiquitous it's in the php community and all it's adapters to various logging backends.

It depends. I'm actually regretting going that path for an application of mine, because it pushes so many if/else conditionals in your controllers/view layer, which could otherwise be handled by a single user class as part of the application domain. But it really depends on how separated your user types are in the application. Edit: Also different user templates don't allow users to be of multiple of those user types.

That's strange, this should normally be handled by the file compiler (and it works for my few pw 3 installations).

Getting just the folder means $file is actually not a file (Pagefile), but a Pagefiles object. File fields are internally always handled as list of files, so you might need to use the following or alike: $file = $upload->file->first();

Just removing that line won't work. It's just there so PW knows under which db engine it was installed. Changing it will not modify the database in any way to actually resolve the issue.

There are redirects to https, but when redirecting all post data sent with the request are lost, therefore forms won't work if they explicitly use the http protocol.

If you're asking for ready to use plugins I doubt ProcessWire is the correct system for you. There are various modules for processwire, but they tend to keep a small footprint and most don't even create any predefined markup. While it's still a nice system you'd need to be able to implement (at least most of) your business logic on your own. In regards to webapps we're probably closer to some php framework than we are to wordpress, where you just have to install some stuff. So it really depends on your skillset and/or willingness to learn some things on the way.

All $config->ajax does is checking for the request header "X-Requested-With", which is not even a real standard. It is included in jquery's ajax tools by default, but most modern ajax libraries don't do that anymore. There's nothing more to it.

I'd really rather suspect that then WireMail not sending newlines. Still could be a bug in one of the 3.0 additions to wiremail.

If you want to get involved I'd suggest you to add your thought to the mentioned PW branding thread. It's basically our most current state of branding and evolving from there would probably be the best.

WireMail is there to send mails and not to care about what it's sending or how that markup is created. You can create the html markup, which should be sent, in whichever way you desire. It could be a page being rendered, there's wirePopulateStringTags() or you could stitch together strings in php. That doesn't sound right.

First of all, so the whole post doesn't sound overly harsh and negative: It's great to see that you want to help out and change something, but the way you took might not have been the best one. So now we have four of them. The problem the project does have in terms of corporate identity is not the lack of a good logo (our latest one present in the uikit theme is actually quite nice), but rather that it's hard to get things changed to one consistent look if there isn't one driving force behind that change with all the needed access. E.g. even just the processwire website has naturally grown to consist of about 4-5 destinct parts, which would need to be updated. And there's not only the logo, but the whole site could sport a freshed up look. It would clearly be nice to have those changes be done more quickly, but to be honest it's only Ryan who could lead the whole process to an end and he has a lot more than just this topic on his todo list. There's certainly willingness in the community to help out, but too many cooks spoil the broth and it'll still need Ryan to be involved in the process to at least lead the whole effort.

It depends on the use-case. Take a look at vue-i18n. You could probably provide the translations via json fueled by processwire's translation features. Server-side rendering is only supported in node (and not just V8, which could be run in php). Therefore you'd need to add yet another environment to your stack. I'd only go that route if you're creating a fully (node served) vuejs app with processwire just serving data via an api. Without the dev server (and hot module replacement) developing anything more in the SPA direction will be a pain, so yeah it does make sense. You could also use processwire like you do without webpack and just switch the javascript url in your template to the url webpack does provide the script on.

You can certainly create your own custom user listers with ListerPro, but it's neither adviced nor praticable, because the ProcessUser module does handle a lot of the permission issues regarding user pages, which those custom lister pages of ListerPro won't handle.

You can filter users out by all sorts of rules, but you cannot easily create additional user listers like you could for plain pages with ListerPro. Sadly there aren't any bookmarks for the users lister as well, where one could save often used filters. I hope Ryan will add those some time.

You might want to add hour/minute(/seconds) definitions as well or you might miss some edge cases in comparing those timestamps. It's not only comparing the date part.

@modifiedcontent Please do not double post, just look at the provided answers under your post here:

This is directly from demo.processwire.com, I'm sure the lister filters are enough to manage not only a small number of users.

Oh, yeah these aren't WireData objects, but plain arrays. You could however use plain php array sorting or convert the entries to WireData objects.

PHP can only use the languages installed on the host environment, e.g. the server. Otherwise setlocale() won't work.

Try this: $forms->get("reserveren")->entries->find("id>0")->sort($entry['datum']) It should however work if one is loading all entries beforehand and doing the sorting in memory.