LostKobrakai

https://processwire.com/api/ref/page/next-all/ / https://processwire.com/api/ref/page/prev-all/

You can do it to the degree forums do it. Like track users activity somewhere in a database whenever communication happens and take some amount of timeout at which you consider a person without activity offline. What you cannot easily do is online users to the degree you would expect it from e.g. a chat platform, where you actually want to detect if someone is leaving without waiting 15 minutes and without them needing to communicate to your server constantly. This is the realm of websockets. I may be biased, but if you want a really proper (and scalable) solution for that problem take a look at: https://dockyard.com/blog/2016/03/25/what-makes-phoenix-presence-special-sneak-peek

This is certainly nothing, which can be answered in absolute terms. File system speed depends on the filesystem. A RAM disk is way faster than some old-ish HDD. The database might be local and mostly in RAM, but could be on another machine with network latency to consider. You'd need to test this on the actual machine you're working with under the expected load you're working with. If you're already doing much filesystem IO WireCache might perform better. If you filesystem IO is not saturated, but your db is queried a ton, then adding even more load to the db might not be the best choice. The latter is probably the more usual case for ProcessWire usage. Attention seems like one of the worst metric to judge the usefulness of features by. Afaik WireCache was added to allow for caching of actual data (like pagearrays), which is something MarkupCache simply could not do and cannot do. If you don't need that as a feature performance would be the only thing I would care for.

That only works well for a single currency. If you need to support any currency you should really use decimals, as different currencies are differently subdivided.

There are precision issues with float, but by my understanding the issue here is with the rounding and not the precision.

I personally see just a single benefit in the functions api: It's beginner friendly as it's keeping you from needing to understand how scoping and classes work in php/pw. But it brings the the big downside of relying on a global processwire instance, which is a well known code smell. It might not matter for many simple websites, but especially in modules one should never use those as it will simply prevent the module from being usable in a multi instance setup. Currently I feel like the tradeoffs and why one would use one API access method over the other just isn't very well described. Maybe something of this post could be incorporated into the current explanations:

I don't particularly like the handling of datetimes in processwire very much. Imho the unformatted value of those should be a proper DateTime object if not carbon.

You're talking about wall-time. To be really save for future dates you need to store not only the datetime (UTC) + timezone, but also the wall time. There are changes in timezones multiple times per year and some are even countries changing how their timezones work. If you have both UTC and wall-time you can detect such changes and react accordingly. The UTC time you need as soon as you need to compare / act on times, which are in multiple timezones, you need to interact with some APIs or export .ics calendar files. So for your examples it might be fine to disregard the timezone and only use wall-time. Here's some more information on why timezones are hard: https://zachholman.com/talk/utc-is-enough-for-everyone-right I've also found this to be a good blog with a bit more actionable advice: http://www.creativedeletion.com/

What you do is basically reverse-engineering the selectors uikit is building. When uikit updates you need to update. @bernhard goes the other way around, which is quite a bit more future-prove as configuration happens before uikit does it's thing.

The problem behind 2. is probably due to the fact that any core code will still create new pages using new Page(), which will create a Page class and not a pageClass class. So any code running within that request will get a Page. On the next request the page will be loaded from the db and therefore the correct pageClass will be used. About 1.: It's not beta in any ways. E.g. the core User class is using the same system. It's hidden behind the advanced flag simply because you can create a big mess if you're not using it correctly. Imagine you use a pageClass, which does not extend PagesType, but is just some random class. It would probably break quite a lot of things in your website. It's also certainly an option your average developer shouldn't use especially without knowing what those setting do. "ProcessWire system development" does actually mean what it says. The pageClass option is there because the core uses it for its user pages. Ryan might use it for different pages in the future and if you override it it might clash and break your site. It's quite unlikely (there's been no need for years), but possible.

I think you both have valid points. If ProcessWire wants to get more exposure and usage (…more devs creating quality modules) there are lot's of places to advance or update documentation or educate better. Especially module development can easily be daunting to newcomers as it's basically "do what you want" besides some conventions around config / module info / process module callbacks. There could also be more (UI) components to make processwire modules really feel like integrated into the backend. Currently this is mostly on the module developer which is neither efficient nor works really well. Besides the InputfieldWrapper and MarkupAdminDataTable component I feel like there's a severe lack of consistency in the ProcessWire UI a.k.a. truely reusable UI components to be used by module devs. One can certainly do a lot with just those two, but that depends on the module. It should be perfectly fine to talk about such shortcomings. Especially if it's the experience of someone new here it should be a clear sign about places to improve. What we should be aware though is that we're still talking about oss and resources are sparse. Ryan will do what he can in the places he thinks are most important. This might not necessarily align with what other people think is most important. E.g. from my years in this community I feel like Ryan sees ProcessWire much less as a CMF than many people use it as. So the developer turning the admin experience around by 180 degrees is not really the primary target group. This explains any lack of grand documentation in this place and maybe the quite a few modules needing to fill in the gaps.

The text is talking about server side session handling. The default in php is to store files in the filesystem with session identifiers, which historically was more prone to security issues on shared hostings than the database. Most services I use nowadays got their filesystem permissions properly under control though, so this hopefully is a thing of the past. Php does also support other storages for sessions out of the box like redis or memcache. ProcessWire also comes with SessionHandlerDB, which stores the session identifier in the MySQL database next to all the other data it needs to store. This is an easy solution, but makes your application more difficult to scale independently depending on the load you get. $session is the API variable, by which you work with said php session of users in ProcessWire. Everything mentioned by now is totally unrelated to client side storage like the html5 sessionStorage. This has the name "session" in it not because it somehow relates to server side session handling, but because it lasts only for a certain browser session a.k.a. it's wiped as soon as you close your browser. It's just a property for the "Storage" it provides in terms of expiration of data. Depending on what you want to do server side sessions and the sessionStorage of your browser can both provide a solution, but ultimately they work vastly different and you need to decide based on the tradeoffs what you should ultimately use.

Graphql is a query language you most often use for frontend/backend interaction or even public apis (kinda an alternative to rest). You wouldn't want to give random users direct access to sql though.

That's totally fine. We could simply not support different formats besides webp for now. I was really just talking about the configuration, so if there is time in the future to have a more extensive featureset supported we don't need to change the configuration, but can just add the features / remove warnings.

Can we make the api a bit more flexible like: $options = [ 'additionalFormats': ['webp'], 'webp' => [ 'quality' => 80 ] ]; This way we can easily add any other formats, which might emerge and have the possibility to not only have a single additional format generated. And as soon as we might generate multiple formats / images per sizing operation I feel like namespacing options like quality might prevent an explosion of possible root level options.

The crux here is that the file compiler usually takes care of older modules, which are not namespaced. Maybe those additional files are expected to be namespaced by the file compiler if your main module is namespaced.

You namespaced the file containing the module, but not the two other files. Namespaces are always per file, therefore each one needs the namespace declaration.

Or just put that in the settings: { "files.associations": { "*.module": "php" } }

Did you try: $cities = wire('pages')->find('template=city, children.children.created<"14 days ago", !children.children.created>"14 days ago"') Without the @ syntax the two selectors for children should work if they match on different children.

For composer itself: interoperability and a far bigger ecosystem. For wrapping packages into pw modules: Please don't wrap packages for the sake of wrapping them. It's useful if you provide additional features like configuration through the modules or deeper integration in processwire classes, but that's work and needs to be maintained on top of the package by itself. The only backdraw a plain composer package has on top of a pw module without additional features, is that it can't be installed via the backend, but you need to use the composer cli (and that's more a restriction of composer than of pw). The same is actually also true for the few pw modules which install composer packages. Another problem of wrapping packages is that you cannot get updates without the wrapping module being updated. There is also lot's of tooling like checking for security issues around composer. For anyone not just doing php as a hobby I don't see a reason not to use composer just like nobody uses javascript without npm anymore for any serious work.

That's what I was refering to. Afaik /vendor is not blocked by default just because there are packages out there containing assets, which need to be web-accessable. I'd personally also lean to just block it.

Just to clarify the bit about "putting stuff outside the webroot" for security reasons: This is certainly a nice precaution, but processwire is not using it because there are way to many shared hosters, where it's simply not possible to go outside the webroot. I'd also say that if your webserver is not behaving correctly you've got bigger problems to deal with, so usually just adjusting your .htaccess file should be perfectly fine as well. Especially as your php process still needs to be able to read things even if they're not within the webroot to be able to execute them. There's not really a need for composer for that part as processwire has it's own psr-4 compatible classloader: https://processwire.com/api/ref/class-loader/

This seems to be an index page. Are you sure the error happens on the first item of the collection? In other words did you check all items for that key as you‘ve only posted one here.

There are three things to consider for load balancing: You need a central database, central file management (if people do upload things) and central session management (as the default also uses the filesystem). Each can be solved in various ways and depends mostly on your project's constraints. Database Probably as simple as running the db on it's own external server. File Management - Cloud storage (S3 or equivalent; minio for self hosted S3) - rsync (this is at best eventually consistent as you need to wait for the sync) - mount network share (I've not tried this and read a lot of bad things, but it might work) Session Management - Use the central db for session (SessionHandlerDB; might be slow) - Use a central redis server (can be done directly in php)

Hooks are the way to go for validating business requirements.