Jump to content

teppo

PW-Moderators
  • Content Count

    2,676
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by teppo

  1. 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?
  2. @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 πŸ™‚
  3. @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 πŸ€”
  4. I'd say that the FormBuilder support forum is the best way to get his attention.
  5. 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 πŸ™‚
  6. Check /wire/core/ProcessWire.php. Version number is split into major, minor, and revision properties.
  7. 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 πŸ™‚
  8. 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 🀞
  9. 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?
  10. 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 πŸ™‚
  11. 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.
  12. 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) πŸ™‚
  13. 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? πŸ™‚
  14. 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 πŸ™‚
  15. @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 πŸ™‚
  16. 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 πŸ™‚
  17. 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 πŸ™‚
  18. 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.
  19. Right, forgot that one! It's fixed now in the latest release.
  20. 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!
  21. 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.
  22. 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?
  23. Awesome β€” thanks for digging these out! πŸ™‚
  24. 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 πŸ€·β€β™‚οΈ
  25. 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... πŸ™‚
Γ—
Γ—
  • Create New...