teppo

Heard of it, but not tried it. For now I think I'd rather keep issues and requests in one place, and discussions here at the forum. Definitely something to keep in mind though ?

Hey @szabesz, Sorry for the delayed answer, busy week here ? Public RSS feed is rendered by ProcessChangelogRSS module, which hooks into ProcessPageView::pageNotFound. If you can, you could... a) check if the module gets called properly (by adding some debug code to init() method), b) check if the hook gets triggered — in which case we could rule out any config setting or key related issues —, and c) if not, make sure that code in templates or some other module is not preventing the hook from working (URL segments being enabled on the home template is potential culprit, because 404 needs to be triggered in specific way or hooks no longer work as expected). Of course it could be an issue with the module as well, but it did work last time I used it... which was a while ago ? If I recall correctly, I added this as a sort of "power user feature", so that while it can be used, it's intentionally somewhat obscure. This is in part because the data structure for Process Changelog is really quite awful for that sort of query. Anyway, I'll look into this (https://github.com/teppokoivula/ProcessChangelog/issues/33) ? Makes sense to me. I'll look into this as well (https://github.com/teppokoivula/ProcessChangelog/issues/34). That's a quick one: I've never used this combination. In fact I don't think I've ever used ProDrafts, apart from some quick tests way, way back. If changes made while ProDrafts are made to pages, they'll get logged. If it has a custom data storage or if it prevents hooks from running, then they won't be logged. I don't have a test setup for this at hand, so can't confrim this easily. There's a hookable method — ProcessChangelogHooks::shouldLogPageEvent($page, $field, $operation) — which you could likely use to prevent Process Changelog from logging such events, at least assuming that there's something about the Page or Field (alone, or in combination with session data, etc.) that makes such edits identificable. In other words I'm pretty sure that this is doable, but it may well require custom hook. Let me know if you try this, and perhaps I can help with getting that setup up and running. Though, again, I've zero experience with ProDrafts, so... ?

In recent (4.x) versions of ProCache the docblock for ProCache::___allowCacheForPage suggest that it might be a good place to hook to prevent cache file from being created. I'd probably try hooking there and setting return value to false in case a specific env variable is defined (or not defined). Other than that... no obvious solutions here.

With identical modification this is working fine for me. Are other config variables working as expected? Any chance that there's a compiled version or some sort of cache in play here?

Correct ?

Same issue here in terms of links pointing to wrong location (virtualbox based dev environment). Not a big deal for me personally, but sure it would be nice if they worked. Just had a look and I'm wondering if there's a real need for the "Only used if you are viewing a live site" part — why does it work like that, and could it be overridden somehow? I guess it makes sense if "local" means that you're literally developing on the local machine without any extra layers, but since "local" is also used to identify other whether this is a "development environment" vs. "production environment", this is indeed problematic ? Developer specific config file would also make sense because the developer is not necessarily logged in when viewing Tracy panels. It'd be even harder to distinguish between guests ?

Hey Steve, If you're happy to add some logic to config, this was added recently: https://github.com/adrianbj/TracyDebugger/issues/56

You're right (of course). Just double-checked with earlier Tracy version, and no slow-downs for non-authenticated requests. Could've been an indirect result, i.e. my authenticated requests might've slowed entire server down considerably, which in turn would result in visible delays for others. Other than that... no idea, but things seem to be working well now ?

Likely yes. I did notice as well that requests that missed the (Cloudflare) cache seemed sluggish. The server was struggling under the load, so even requests served via ProCache were unusually slow.

To be fair it was largely my own fault for letting the log file blow up. Anyway, a splendid performance boost ? Interestingly I had this module installed. Might've been a configuration error or something; should probably give it another try ?

Confirmed. Added some extra lines to the log to make sure, and rendering the Tracy Logs panel went from 16863.97 ms to 5.2 ms. A lot faster indeed ?

Hey Adrian (and others, in case anyone else happens to run into this issue)! I'm posting here instead of opening a GitHub issue since this doesn't feel like a "bug" or "issue", but rather "a potential gotcha": The background is that I've been recently dealing with major performance issues at weekly.pw. Every request was taking 10+ seconds, which made editing content... let's say an interesting experience. Particularly when PW triggers additional HTTP requests for a number of things, from checking if a page exists to the link editor modal window. Makes one think twice before clicking or hovering over anything in the admin... ? I've tried to debug the issue with little luck, eventually deciding to blame it on the server (sorry, Contabo!) until today — accidentally, while migrating the site to a new server — finally figured out that the real problem was in fact the Tracy Logs panel and a ~800M, ~3.5 million row logs/tracy/error.log file. The underlying reason for this were warnings generated by the XML sitemap module: each request was generating ~2.5k new rows, with an hour long cache, so potentially 60k or more new rows per day. Now, I'm writing this half hoping that if someone else runs into similar problem they'll be smarter than me and check if any of the Tracy panels suffer from slow rendering time (which is already reported for each panel individually), but I do also wonder if there's something that could automatically prevent this? Perhaps logs should be pruned, Tracy should warn if there's crazy amount of data in one of the log files, or log file reading could be somehow optimized? Food for thought. Again this is obviously not a bug, but still something that can end up biting you pretty hard ?

I've not participated much here, since I feel there are more knowledgeable folks here already, but a few quick (?) opinions/experiences: I would love to have an easy way to migrate changes for fields and templates between environments, and version control all of that. I've had cases where I've made a change, only to realize that it wasn't such a good idea (or better yet, have a client realize that) and off we go to manually undo said change. Sometimes in quite a bit of hurry. These are among the situations in which an easy rollback feature would be highly appreciated. I do like making changes via ProcessWire's UI, but at the same time I strongly dislike having to do the exact same thing more than once. Once is fun, but having to redo things (especially from memory, and potentially multiple times) is definitely not what I'd like to spend my time doing ? I've worked on both solo projects, and projects with a relatively big team. While versioning schema and easily switching between different versions is IMHO already very useful for solo projects, it becomes — as was nicely explained by MoritzLost earlier — near must-have when you're working with a team, switching between branches, participating in code reviews, etc. I'll be the first one to admit that my memory is nowhere near impeccable. Just today I worked on a project I last worked on friday — four days ago! — and couldn't for the life of me remember exactly what I'd done to the schema and why. Now imagine having to remember why something was set in a specific way years ago, and if altering it will result in issues down the stream. Also, what if it was done by someone else, who no longer works on your team... ? Something I might add is that, at least in my case, large rewrites etc. often mean that new code is no longer compatible with old data structures. For me it's pretty rare for these things to be strictly tied to one part of the site, or perhaps new templates/fields only. Unless both you and the client are happy to maintain two sets of everything, possibly for extended periods on time, that's going to be a difficult task to handle without some type of automation, especially if/when downtime is not an option. Anyway, I guess a lions share of this discussion boils down to the type of projects we typically work on, and of course different experiences and preferences ?‍♂️ As for the solutions we've been presented with: I've personally been enjoying module management via Composer. Not only does this make it possible to version control things and keep environments in sync, it also makes deploying updates a breeze. As I've said before, in my opinion the biggest issue here is that not all modules are installable this way, but that's an issue that can be solved (in more than one way). While I think I understand what MoritzLost in particular has been saying about template/field definitions, personally I'm mostly happy with well defined migrations. In my opinion the work Bernhard has put in this area is superb, and definitely a promising route to explore further. One thing I'd like to hear more is that how do other systems with so-called declarative config handle actual data? Some of you have made it sound very easy, so is there an obvious solution that I'm missing, or does it just mean that data is dropped (or alternatively left somewhere, unseen and unused) when the schema updates? Full disclosure: I also work on WordPress projects where "custom fields" are managed via ACF + ACF Composer and "custom post types" via Extended CPTs + Poet. Said tools make it easy to define and deploy schema updates, but there's no out-of-the-box method for migrating data from one schema version to another (that I'm aware of). And this is one of the reasons why I think migrations sometimes make more sense; at least they can be written in a way that allows them to be reverted without data loss.

That does seem like an issue. I have a vague memory that I might've had to make changes related to the timestamps at some point in the past, but can't remember what it was all about. For the time being I'll open a GitHub issue for this, as it might require a bit of digging and testing to make sure that everything works as expected ?

Switched all my personal sites to the latest dev branch last week (after accidentally updating the server from PHP 8 to 8.1 — whoops...) and have had no issues — as far as I know — so far. Apart from a few minor ones (deprecation warnings) related to PHP 8.1, but those are already reported via GitHub. I'd say that it seems pretty solid so far ?

This API ref page is pretty low level — so yes, the core does (by default and automatically) track changes made to pages, but it's mainly for checking if a specific Page object was changed during this particular request. The core itself doesn't maintain a log of changed pages, that's usually where modules step in. I'm not entirely sure what this module is; you're not referring to Activity Log, are you? Anyway, a module that tracks changes should be able to keep track of changes made via API as well, with just one exception: if the API request is made with the noHooks option enabled, no module will be able to track that. In other words API requests alone are nothing special, so they should be tracked normally, unless the one triggering said API request is specifically preventing any hooks from running, in which case there's no (clean) way to intercept or track it ?

To be fair it's kind of cheap to blame this particular issue on WordPress. An unrelated vendor was compromised, which is something that could happen to pretty much any platform out there. In this sense ProcessWire isn't much (if any) safer at its core. Just saying. If there's a lesson here, it's probably that "anyone can be compromised". This was a vendor considered trustworthy by hundreds of thousands of users, after all. And perhaps another lesson might be that "relying on third party vendors can be an issue" — although writing every bit of code yourself isn't exactly a silver bullet either ? (In the video above they also put plenty of blame on PHP as a programming language, argue that the issue is due to WordPress being "pretty old" — like new software was inherently more secure than actively maintained older software — etc. There were some valid points there as well, but blanket statements like that... ugh ?)

Sure, that'd be great ?

It should definitely work with $this->view->setTemplate(), like Zeka said above — though let me know if it doesn't, and I'll look into it ?

A bit of background: rendering partials (using the partial name as method) is a relatively new addition, while including partials with chained syntax (<?php include $partials->common->summary ?>) has been an option since the very beginning. I don't have a strong opinion about what should be the default behaviour, but the main reason why I likely won't change this is that it would potentially break a lot of sites ? At this point I would recommend against partial names with dots or dashes. Personally I tend to use snake_case for naming, as I find that the most sensible option: dashes or dots won't work, and camelCase and PascalCase are prone to errors (although it's customary to use them in class names). It is actually possible to access properties with dashes as well, but it's not exactly pretty: <?= $partials->common->{'summary-block'}(['heading' => 'Hi!']) ?>. Extending $partials->get() with support for paths does seem like a good idea, though, so I'll add this to my todo list ?

Sorry for missing this question — and no, it doesn't seem like intended behaviour. I've made some adjustments to the latest version, 0.30.4, that should make things better in this regard. At least it helped with these exact terms (business/businesses/businessmen) in my limited tests. Please let me know if this doesn't work, or if it makes things somehow worse, though ?

Very good points there and definitely a big thumbs up for this topic in general, but not sure if I can fully agree with this part: Any module that supports Hari's composer installer, Wireframe composer installer, or the official composer installers package will automatically be installed in the correct directory. Technically only requirements are that the module includes composer.json, and is marked as pw-module or processwire-module. If you're using a custom directory structure (like we do), you'll indeed need a config setting in your main composer.json to specify where your modules directory is located — but even then it's a once-per-project thing. Hari's installer doesn't support this but others do, and Wireframe installer will also automatically detect any module's using Hari's installer and override it to make this work. On a loosely related note, in case module authors are reading this: Hari's installer may still be the most popular option, but it's somewhat outdated. It lacks support for Composer 2, doesn't provide any configuration settings, etc. I would strongly recommend moving to more recent (and actively maintained) alternatives. I always add the modules directory to Git ignore, so it's definitely doable. This works out of the box for composer installed modules, and modules that are not installed via composer can still be added to the repository with the -f flag, which essentially makes Git ignore the ignore rule. Only problem would be modules added in a production environment via GUI, but since we're talking about version controlling stuff, this doesn't seem like a particularly relevant concern to me. In case of modules that don't support Composer installation, creating a private fork is of course always an option. This works nicely for commercial modules as well, but requires installing said modules via Git repository (which is a bit clunky), or via private Packagist (which is more elegant, but requires paid plan.) In my setup ProcessWire is installed and updated via Composer. Again doable, but this part could admittedly be more elegant: since the wire directory needs to be in a publicly accessible location, typically you'll need post-install-cmd/post-update-cmd in your composer.json (or something similar) to move / copy said directory from vendor to another location. Anyway, would definitely like to see this topic getting more attention in future releases. And it would of course be great if more module authors would add their modules to Packagist — that would make things easier for Composer users, and setting this up is quite straightforward. ? In WP plugin installs via Composer are — for the most part — solved by wpackagist.org, which mirrors all plugins in the official plugins directory. In a nutshell this means that plugin authors just need to submit their plugins to the directory, and they automatically become installable via Composer (composer install wpackagist-plugin/plugin-name). Having something like that for PW would be an interesting option for sure.

15 inch MacBook Pro, no external monitors. I'm used to pretty small print — cranking the resolution setting to max space and then decreasing the font size a few times works wonders ?

Talking about dinosaurs... (To be fair I'm mostly just a "late adopter". I don't mind trying out new stuff, but rarely jump to new tools until they've been battle tested first.) IDE: VSCode, with a bunch of handy extensions (PHP Intelephense, Tailwind CSS IntelliSense, SCSS IntelliSense, phpcs, EditorConfig for VS Code, Git Blame, GitLens, Remote, etc.) Emacs when it makes sense to work on the live server, or I just need to make a few quick changes for a local site — though Remote extension for VScode works really well over SSH, so been using that more lately ? Dev environment: VirtualBox or Docker, depending on the project. Some of my own old projects, mostly the ones that I rarely need to touch, I tinker with on the live server ? Staging... is not really a part of my usual process. Changes go from local dev environment to live server ?‍♂️ Syncing between environments: combination of (bash) shell scripts and rsync ? Hosting: AWS for client stuff, Contabo for personal projects. Currently considering switching away from Contabo. It's super cheap, but sluggish. Could be my own making, but I would happily spend a few more bucks a month if it helps. Modules: that's a long list, but development oriented ones are Tracy, Wireframe, and lately ProfilerPro. Other modules I use on pretty much all sites include AdminBar, MarkupMenu, SearchEngine, ProCache, ProFields (particularly Repeater Matrix), FormBuilder, SchedulePages, Redirects, Process Changelog, Process Login History, WireMailMailgun, PrivacyWire ... and a handful of others, many of which were built by @Robin S ? Front-end: Tailwind CSS + build process powered by Gulp. Vue for some JS work, but mostly just plain old JS/ES. With all the goodies baked into the language nowadays, jQuery is obsolete. (Literally have had one case where I wanted to use it in the past two or three years: needed to serialize form data.) What else? Composer for managing PHP libraries and ProcessWire modules, NPM for JS, Git for version control (surprise). Think that's just about it ?

This was in the support area for Repeater Matrix, so not on the public forum.