Jump to content

teppo

PW-Moderators
  • Content Count

    2,577
  • Joined

  • Last visited

  • Days Won

    66

Everything posted by teppo

  1. @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 πŸ™‚
  2. 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 πŸ™‚
  3. 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 πŸ™‚
  4. 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.
  5. Right, forgot that one! It's fixed now in the latest release.
  6. 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!
  7. 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.
  8. 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?
  9. Awesome β€” thanks for digging these out! πŸ™‚
  10. 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 πŸ€·β€β™‚οΈ
  11. 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... πŸ™‚
  12. 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 πŸ™‚
  13. 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.
  14. Just my five cents: this project seems like something that would be very useful without any support for recurring. I'd love to get my hands on this feature, and I'm pretty sure I'll never even need that latter part. In fact more commonly I've needed reoccurring events (hope that makes sense; basically I mean events with multiple, manually specified dates rather than a set of rules to govern when and how often they should recur). Recurring rules can get extremely complicated: "this event occurs every Friday between January and August except specific days x, y, and z β€” and then it also occurs on this particular Wednesday and that Tuesday there, but on those days there needs to be this additional note on the content". Done that a few times, but I try my best to steer away from those implementations. It's very rarely worth the hassle. In my experience lot of that mess can be circumvented by allowing multiple dates (or date ranges) for one event πŸ˜‰
  15. This is a good point! In one case we needed a set of "real-time" statistics displayed on all pages of a site. Though the site was internal, it was relatively heavy on traffic (lots of users reloading it all the time), and users very much depended on it being fast, as it was an integral part of their workflow. The solution we came up with was a simple cron script that pulled the data from a separate database, wrote it to a text document on the disk, and then (an equally simple) JS script that polled that text file and injected the content on the page. Technically the solution had nothing to do with ProcessWire β€” just that the result was injected (via JS) within otherwise "static" content πŸ˜… Actually... you can always embed Vue apps within a ProcessWire generated page. In my experience Vue is pretty great for that sort of stuff in fact. But of course you don't have to do that here, and the jQuery / vanilla JS route is pretty much guaranteed to be much simpler πŸ˜›
  16. That works as well! Main reasons I don't (practically) ever use this approach have already been mentioned here: I'd have to block access on template level (may need to do that on a lot of places), search features and highlight lists etc. all have to be aware of this, and so on and so forth. Potentially having multiple developers work on the site doesn't really help either. At some point you're very likely to show publicly something you didn't intend to. Want to schedule pages? install SchedulePages. Need more scheduled content? Add two fields to the template. Easy as it gets πŸ˜‹ Also, as a general rule if thumb, I try to do as little permission/access checking myself as possible. Sure, in this case it's probably not a big deal, but... 😁 "ProcessWire β€” there's more than one way to do it" ✌
  17. Thanks @Mikie! I'll take a closer look at this ASAP πŸ™‚
  18. SignalR apparently uses WebSockets behind the scenes to achieve a "real" push effect. I'm not at all familiar with this technology, but if you really need push (instead of polling the server periodically as in the example above β€” which, for the record, is in most cases quite enough), you could look into something like Ratchet (a PHP WebSocket implementation), or perhaps build that part of the site in JS and then use pretty much anything as the back-end (Node, etc.) Anyway, you're right in assuming that ProcessWire doesn't have anything built-in for this particular need. ProcessWire provides tools for managing content; what you do with that content is not its concern, and technically "pushing the content to the client via WebSocket" is more a matter of presentation than content management πŸ™‚
  19. Title text is not a best practice when it comes to usability; visible text would be best. Not just because things shouldn't be hidden (unless there's a good reason for it, which I really don't see here), but also because it'll be a problem from accessibility point of view, for touch screen users, etc. Overall there are very few cases where the title attribute should be used πŸ™‚ This makes sense πŸ™‚ I think your suggestions are already pretty good! "Show time input" could be just "show time" perhaps? And "show end input" could also be something along the lines of "date range", though not sure about that one. This brings to mind one question: what do you think about making the labels configurable? For an example if we're talking about events, a label such as "all day event" would probably make most sense (and Outlook Calendar uses this as well, so it's somewhat likely to be familiar to users), but events are not the only use case, so the default label probably shouldn't mention "event" specifically πŸ™‚
  20. To be fair publishing (or un-publishing) pages at set time vs. just listing pages based on a datetime field are two different use cases. In some cases the distinction may not matter, but in others it will β€” i.e. when something really shouldn't be viewable before a predefined date/time πŸ™‚
  21. If I understood this correctly (instead of text, there's now just an icon?) I would actually recommend against this β€” simply because icons will never be as obvious as text labels. From an usability point of view text labels are much better πŸ™‚ From an accessibility point of view, on the other hand, this is just fine β€” as long as your checkboxes still have proper labels. If the icons are images an alt text is quite enough, but if they're something else (<i> with FA classes etc.) you should hide them from screen readers with aria-hidden="true" and then introduce a separate screen reader only text version.
  22. Another SchedulePages user here. Works just fine for PW3 πŸ™‚
  23. Managed to miss this one. Check /site/config.php, you should find the database host/domain, credentials, etc. from there.
  24. Hey! Bernhard already summarised the steps quite nicely above, but one thing I'd like to add is that if you do run into Windows specific issues, you might find solutions from some of the existing threads β€” e.g. On a loosely related note, the forum search can be pretty horrible at times, so if you're looking for something specific you'll usually have better luck googling for it (site:processwire.com/talk) πŸ™‚
  25. Just an idea: it's not the most street credible way to use Vue, but if you've got an existing app and you want to give it a try to see how it would work for you, adding it via a CDN is always an option. You won't get the benefits of a build process or all of the benefits of a full blown JavaScript framework, but what you should get is a rough idea if Vue is the right fit for your needs. Once you've (re)built a part of the admin side with Vue, you can decide to either dive in deeper, or just stick to good old jQuery+HTML πŸ™‚ Even if you go with the full "vue create app" route, you don't have to rewrite your entire site. For an example I recently built a PW website with a single Vue app embedded within β€” a member catalogue with a lot of data, sorting, filtering, etc. involved. Would've been a major headache with jQuery+HTML, but Vue made it pretty easy. I used Axios and treated one path of the PW site as a simple JSON API, which was β€” apart from some head scratching related to Access-Control-Allow-* headers β€” basically a no-brainer. Would do it again. Note: in the example above the page itself is served via PW (we've also done full-blown Vue SPA's with ProcessWire, but that's a very different route). Vue app is built in a separate location, generated JS file and required assets are moved to a directory within /site/templates/, and then the JS file is embedded within the page's markup. PW outputs a HTML element with an ID, which you then tell Vue to render the app in.
Γ—
Γ—
  • Create New...