teppo

@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) ?

I don't see anything obviously wrong in your screenshots. This is probably a dumb question, but just checking: you've also added a page using the "floodcases" template somewhere? ?

Tailwind user here! I'd definitely recommend checking Tailwind out. Where it really shines, in my opinion, is any kind of rapid development / fast prototyping: add a bit of (semantic) HTML and sprinkle it with a bunch of classes and you'll have a good looking site in no time. One downside, though, is that when you're building something really big, it can easily get out of hand unless you set some ground rules / constraints for yourself in terms of how many spacing variations, colours, etc. you're going to use. If you don't, you're going to end up with an end product that looks inconsistent, is a lot of work to maintain/refactor, etc. ? As a matter of fact Tailwind is unopinionated: the framework doesn't come with any pre-built components, so it's entirely up to you what you build with it. Only features in Tailwind that could be considered somewhat opinionated would be things like the default colour palette, shadow styles, spacings, etc... but you can easily override all that. And for those who actually prefer pre-built components, there's a new (commercial) project just being launched called Tailwind UI, which is essentially a library consisting of hundreds of Tailwind based front-end components ? (Also: https://tailwindcomponents.com/. That's the free alternative / predecessor to Tailwind UI.) ... although, all that being said: for my personal projects I've mostly preferred vanilla CSS/JS and a BEM(-ish) structure. Nice and simple ?‍♂️ Back in the day I used to be a big fan of Foundation, but nowadays I find that type of framework mostly a nuisance. Basic things like grids are by now (mostly) solved in CSS, so unless you're intending to use the out-of-the-box components provided by the framework to dictate how you build your front-end, I don't see much sense in going that way. To each their own, though; this sort of thing is largely a matter of taste and habit ?

@benbyf, I merged your question to the ProcessRedirects support board. Similar issue has been raised before, but since this module isn't really maintained anymore, currently your options seem to be... Switch to Jumplinks Try out the fork from @kixe: https://github.com/kixe/ProcessRedirects/tree/kixe In the long term switching to Jumplinks would likely be a better choice. Edit: I'm actually pretty sure that the fork won't fix this. The module creates unique key for redirect_from, which is varchar(256) — and if you're using utf8mb4, this is going over the limit (max key length is 191). I can see two solutions: update the module to limit the key length to 191 or remove said key altogether (though that would likely affect lookup speed negatively). TL;DR: switching to Jumplinks is indeed the sensible thing to do ?

Exactly what BitPoet said. Over the years I've heard over and over again how PHP is a dead/dying language, and how the future is all about [insert any imaginable language here]. If anything, I've learned not to care: PHP has been around for a long time, and to date it's still a lively project with a massive ecosystem. When I started with PHP 4 (or 3 — can't remember for sure) back in the days, it was a whole different language, really. 5.x made it a viable object-oriented language, 7.x brought in massive improvements in terms of features and performance, and 8 looks like it's going to be a blast as well. So yeah, I don't see any reason to jump the ship at this point; if anything, I'm pretty sure that PHP will have a lot more to offer in the future ?

While I agree that securing the superuser account with 2FA — and, preferably, not creating multiple of such accounts — is a very good idea, you can still make sure that even if a superuser account is compromised, it won't provide anyone with any more than the necessary capabilities on the host system. Don't allow PHP to write into directories where executable code is stored; most importantly index/config/htaccess files, /site/modules/, /site/templates/, and /wire/. This means that a) module installs via ProcessWire GUI are out of the question, and b) at least in production you can't use modules that allow authoring or executing code via a GUI. Technically File Compiler also writes executable code, but it's a bit different (and can usually be disabled as well). I wouldn't worry about it too much. While ProcessWire used to allow storing custom code in Page reference field settings, that's no longer the case (hooks are used instead). As such, at the moment I can't think of any core feature that would allow superusers to access the underlying system once aforementioned precautions are taken — so after this it's essentially about only installing modules you know and trust ? Finally — and this is not a ProcessWire thing per se — make sure that the system itself is secure, and that whatever user Apache is running as doesn't have access to anything it doesn't need access to. Also: try not to store anything that doesn't need to be public under a publicly (web)accessible directory, whether or not there's .htaccess protection in place. I won't go into server side security here, but there's a truckload of stuff you can do there both to avoid user accounts being compromised, and to limit the impact of compromised accounts. For an example you can make it so that even if someone does gain shell access through the site, they won't have access to the whole server (this is always the case in shared hosting, at least if the host has any idea whatsoever of what they're doing). Often it all boils down to how hardcore you want to get with this stuff, really ?

As far as I can tell, this favicon line has never been a part of the AdminThemeUikit that is shipped with ProcessWire. Are you sure this wasn't actually a local modification made by you or another developer? In either way it's never a very good idea to modify the contents of the /wire/ directory yourself, so even if there was such a line, adding your own favicon there would be a problem — partly because it will very likely get lost when you update ProcessWire.

Right, forgot that one! It's fixed now in the latest release.

Aforementioned issue should be fixed now. As was already mentioned above, this could only be replicated under specific circumstances on macOS; nevertheless it seems that defining the "u" flag for preg_replace() is a relatively safe thing to do, so I've gone ahead and done that. If it ends up causing trouble, I may have to reconsider that, but at least for now it seems to be all good ? Thanks @Mikie for tracking this down!

It's not so much about Hanna Code specifically, but rather posting (obvious) code via any web form. ModSecurity and different WAF implementations may detect this and assume malicious intent, which is problematic here since we actually want (authenticated) users to be able to post code. The easiest thing to do would be disabling this feature altogether, either globally or at htaccess level for a specific site. I'm not familiar with this solution so I've no idea if there's some way to keep it on for most users and/or just disable parts of it, but you may find more about that from the LiteSpeed manual. Edit: at least in Apache you can wrap <IfModule></IfModule> with <Directory /some/path/on/disk/></Directory>, which might help to selectively disable this feature. And it's also possible to check if a cookie exists, in which case you could sniff for a "wires" cookie first, though I've never tested this in practice and don't know if those will work together.

In most cases (probably all I've heard of so far) this type of issue is caused by the security settings on the host, mod_security (ModSecurity) module, etc. LiteSpeed apparently has its own WAF feature, so that's probably where I'd start digging into this; is something like that enabled, have you recently made any changes on the host, or could the host have been updated by someone else? Has this worked before?

Awesome — thanks for digging these out! ?

Heya! Just wanted to drop a quick note here regarding this point ? I get why you feel that this is a problem and "an ivory-tower approach to things", but it's worth keeping in mind that with all design decision you'll get some benefits, but also some drawbacks. In systems where there's no "true" tree structure (some CMS products have gone this route) this would likely be an easy thing, but since ProcessWire is indeed hierarchical, it's going to need a bit more work. At the same time the structure in ProcessWire is predictable, efficient, and works great when a site consists of a variety of different content types. I've worked with other types of systems as well (including WP), and would choose PW's hierarchy any day over any of the alternatives. Regarding "switching the root", I've run into something similar once, and that's after being around PW for almost a decade and having built, maintained, and rebuilt quite a few ProcessWire sites in that time. What you're asking for may seem like a simple thing, but it's really not (given our context), and it's also quite a rare request — if it wasn't, it'd probably make sense to give it more consideration at core level ? To give you a bit of context, this is roughly the same as a Linux user stating that "I just need to switch the system root, it's an easy thing right?". Well, you can do that as well, but it's really not an easy thing, and may in fact be very destructive (unless you know exactly what you're doing). Again, design decisions; you may disagree with them, but the fact that this issue rarely comes up tells me that this particular design decision was likely a good one. Just my five cents ?‍♂️

Thanks, I'll try to dedicate this a bit more time later today. I'm still confused as for why it's happening (can only assume that there's some difference in the environment), but perhaps the "u" flag indeed is the correct fix. Will have to check that it doesn't cause additional issues in cases where the module is now working as expected... ?

Table field is now one of the supported fieldtypes in SearchEngine 0.17.0. The indexing part makes use of TableRows::render(); I may have to revisit this at some point, but this approach seemed to work quite well in my initial tests, and this way I don't have to identify each possible value but can rather let the fieldtype do all the heavy lifting ?

Heya! I've looked a bit into this, but to be honest I'd like to gain a better understanding of the situation before applying the fix. Any chance you could check the charset and collation of the field_search_index table (assuming search_index is your search index field)? The output of "SHOW FULL COLUMNS FROM field_search_index" should be enough. The "u" modifier for preg_replace() does some things I'm slightly worried about, i.e. it's documented as "not compatible with Perl", it changes how matches are treated, and it may also result in warnings if the subject string invalid UTF-8 — so at the very least it may require a bit of extra validation as well to account for that. Before going there I'd like to figure out how to reproduce this issue first. I've tried all sorts of special characters with no luck, so far everything has worked just fine here ? Also, when you say that the ""à" character it is getting encoded as \xc3 when it should be \xC3\xA0", what do you mean exactly? I mean... do you literally see \xc3 somewhere, or do I have to grab the value and pass it through some sort of inspection process to see that it's wrong? If I dump the result of processIndex(), I see "à" character on the screen, and that's also what's being stored in the database. Sorry, I'm easily confused when it comes to things like character sets etc. ? Edit: forgot to mention that based on StackOverflow this definitely looks like a character set issue, i.e. typical case where this error occurs is when you're trying to store UTF-8 data into a latin1 table. Assuming that the CKEditor field in question is some form of UTF-8, the index field data column should definitely also be UTF-8 — and if it's not, that sounds really weird.