teppo

It looks like you're using Hanna Code with one or more of your indexed fields. Is that correct? Here something is trying to resize a Pageimage object while it's actually a Pageimages object, which usually means that output formatting is off. If so, you could fix this in the Hanna Code snippet itself (by checking for Pageimages and getting the first Pageimage from it). I'll see if there's something I can do to make this work better, but that's the quick fix anyway. (Assuming I understood the stack trace correctly...)

If you view the page source (right-click + view page source, i.e. not the "formatted" version you see in dev tools), is that actually what you see there as well? Since a_01_text is a CKEditor field it'll return markup, and in this case that markup probably consists of a paragraph (<p>Some text</p>). Since you can't have a paragraph inside a paragraph, your browser might be "correcting" it to this. How 'bout converting that wrapping <p> element into a <div> instead? <div class="wow fadeInUp animated" data-wow-delay="1.3s"><?=$page->a_01_text?></div>

function renderCustom(PageArray $items) { foreach($items as $item) { echo $item->title; // ... heavy content loading } } Is this just an example, or is your actual function also just echoing content? If so, that right there could be your problem — echo will output the content right way instead of returning it for assignment. Try something like this instead: function renderCustom(PageArray $items) { $out = ""; foreach($items as $item) { $out .= $item->title; // ... heavy content loading } return $out; }

I think this would be a very good first step, and would probably be quite enough for almost all use cases. If you could make this change, I'd be a very happy user indeed 🙂 Options like these are great to have, but from my point of view automation is always the best solution (if it can be done, that is). After realizing that the cache can now contain pages that are not public I turned to this option, but doing it manually on a site with loads of non-public pages all over the place... not fun 😅 Slightly off-topic: I was under the impression that the "Templates without sitemap access" setting would also affect child pages, removing them from the sitemap, but at least on one site it doesn't work like that: parent page (the one with a template that was specifically selected here) doesn't show up, but its children still do. Not sure if that's a bug or something I've misunderstood?

@Mike Rockett, I think we're talking about different things here. Sorry, my bad — should've been more clear! 🙂 The thing is that currently this module caches content for logged in users as well, which in turn means that the XML sitemap that guest users then view might contain non-public content. This probably shouldn't be the case, at least not by default: if the user is logged in, it would be safer not to cache anything at all, or you may end up with a sitemap that publicly displays content that wasn't meant to be public (even if only URLs and update times)... not to mention that (as you pointed out above) including non publicly viewable URLs is not particularly useful anyway. The idea about including roles in cache key was mostly just so that if there's indeed some use case where folks prefer current behaviour, that could still work. I can't think of many reasons for that either, though, unless it's for some sort of an internal API / index or something 🙂

@Mike Rockett, how do you feel about preventing caching — entirely, or as a config setting — for logged in users? I think it's probably a bit unexpected that sitemap can include pages that guests have no access to 🙂 In cases where sitemap is cached for logged in users, cache key should probably include the roles of the user. That won't be entirely bulletproof, but at least less likely to cause problems 🤔

I'd say that the FormBuilder support forum is the best way to get his attention.

The problem here is not about namespaces, but rather that FormBuilderForm doesn't extend Wire (or any class derived from it), which means that it's not hookable. Long story short: currently you can't add methods to FormBuilderForm with hooks — you could submit a request for this to Ryan, but in the short term I'd recommend finding some other way to do whatever it is that you're ultimately trying to achieve with this method 🙂

Check /wire/core/ProcessWire.php. Version number is split into major, minor, and revision properties.

I'm pretty sure I've also fixed this issue in the 2.0 branch, so updating from there should've fixed this as well 🙂

In the past I've worked with a few translation platforms (Launchpad, Twitter translation center, translate.wordpress.org, etc. — there are plenty of good examples) and one of the projects on my "things I want to do as soon as I find the time" list is a similar platform for ProcessWire. The way I envision this working would be a shared service (website, essentially) where translators can register and do pretty much the same thing they would do in the translations screen in Admin, and then share those projects with others who can both use them and contribute (obviously after an approval process). This would likely be split into "projects" (core, individual core or third party modules, site profiles, etc.) For the site you'd still need a module to install these translations, but the main concept here is a common library of translation files that would do most of the heavy lifting and provide an API for the module. I've been struggling a lot trying to keep up with who manages which translation for what language and where and how (and which version is the recommended, when there are many competing translations), and that's really the biggest thing I'd like to solve with this. In a multi-language environment I feel that this is almost a must-have feature in the long term... and, should it gain some momentum, I could really see that being a valuable addition to our "official site bundle" (translate.processwire.com or something along those lines), though obviously that part depends on how Ryan sees this 🙂 Anyway, just wanted to let you know that you're not along with this need. The problem for me is that I've got a pretty good idea of what I need to do, but I still need the time to do that. I hope to find just that (unless someone nails something similar down first, that is) in a few months, but that's not a certainty yet 🤞

I can confirm this — looks like caching file or image fields in FieldtypeCache doesn't work as expected. Judging from the code changes this has likely been broken since 3.0.142. @Spiria, would you mind opening an issue for this at https://github.com/processwire/processwire-issues?

The replies above by Ryan and BitPoet pretty much covered the questions you raised, so just dropping a quick comment regarding this 🙂 I tend to fuss a lot over things like organising the project, so I'd say that I'm familiar with your concerns. In my opinion a sensible structure is a key design decision, and even more so when you're working with others. So yeah, I can't disagree with anything you've said here. Regardless, after giving this a lot of thought I ended up organising files by type — at least I think that's what you'd call it — in Wireframe. By this I mean that I've indeed bundled controllers in one directory, components in another, views in a third one, etc. For me this just makes more sense: When I add a new template and a view for it (assuming that it isn't already covered by some shared code, which is quite often the case), I'll probably start from the controller. I may copy-paste some parts from other controllers, or perhaps I'll extend another one if I have a very similar need at hand. Some controllers may use other controllers as sort of "subcontrollers", and often there are shared libraries as well. After the "backend" is mostly done, I'll move on to the view in order to actually put those methods to use. In other words I tend to work in layers, going from backend to the frontend. (This is just the way I like to work, and I definitely don't assume everyone to prefer the same approach.) Things like components or partials are made to be shared. If I only need a specific piece of code once — or in one template — then it probably doesn't need to be abstracted away. That'll just make things harder to grasp and add a tiny bit of overhead without actually providing much extra value. Copying files from project to project has been a relatively rare need for me, so when it does come up, it doesn't matter much if I have to copy one directory, or perhaps a couple of files from a couple of directories. That being said: in an old environment this need did come up often (and the structure was pretty complex), so I ended up writing a script to automate it 🙂 It's true that the process of building a new site often involves moving back and forth between backend and frontend, but I still prefer this sort of structure over the alternatives. Also: I find it a tad easier to maintain after the site is already live, since often a specific change will only affect one "layer" of the site. Anyway, this is largely a matter of preference 👌 Exactly. When I first read about custom Page classes, my first thought was that this stuff is frigging cool... but I probably won't be using it anytime soon. I fully agree that it's a great feature, but in my case I've already solved it in a way that — in my opinion — fits my needs better. I may end up using this for some stuff eventually, but right now I don't have a need for it, and that's fine 🙂

Technically it's already possible — you just need to tell WireClassLoader where it can find your custom Page classes. Just gave it a try, adding this to /site/init.php, and it seemed to work fine: $classLoader->addSuffix('Page', __DIR__ . '/templates/page-classes/'); Now ProcessWire checks for Page classes from /site/templates/page-classes/. This is in addition to the default /site/classes/ directory, which still has precedence if a class is found from there.

Just to clarify this a bit: 1. No (out of the box). 3. ProcessWire doesn't enforce any specific architecture on you; instead you can utilise just about any architecture/strategy you want. If you haven't yet had the chance to read https://processwire.com/docs/front-end/output/, I'd suggest checking it out — learning about direct output and delayed output (and their differences) should clear some things up. As @szabesz pointed out above, there are ways to use MVC (or something very similar) on ProcessWire powered sites/apps. In my opinion MVC is great for a lot of stuff, but as always, by design ProcessWire makes zero assumptions: for some use cases simple direct output approach is quite enough, and makes things more straightforward (to build, but also to maintain) 🙂