Jump to content

teppo

PW-Moderators
  • Content Count

    2,680
  • Joined

  • Last visited

  • Days Won

    76

Everything posted by teppo

  1. 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?
  2. Awesome β€” thanks for digging these out! πŸ™‚
  3. 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 πŸ€·β€β™‚οΈ
  4. 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... πŸ™‚
  5. 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 πŸ™‚
  6. 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.
  7. 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 πŸ˜‰
  8. 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 πŸ˜›
  9. 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" ✌
  10. Thanks @Mikie! I'll take a closer look at this ASAP πŸ™‚
  11. 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 πŸ™‚
  12. 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 πŸ™‚
  13. 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 πŸ™‚
  14. 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.
  15. Another SchedulePages user here. Works just fine for PW3 πŸ™‚
  16. Managed to miss this one. Check /site/config.php, you should find the database host/domain, credentials, etc. from there.
  17. 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) πŸ™‚
  18. 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.
  19. I can't properly compare Svelte vs. Vue as I've zero experience from Svelte (and not a whole lot from Vue either), but regarding this question: it depends a lot on how complex stuff you're planning to build. I'm still using jQuery β€” or just vanilla JS, since native features have mostly caught up with jQuery by now β€” for stuff I can do almost completely with plain HTML and CSS (with a PHP backend), while for "complex" front-end stuff where a lot of data is processed, sorted, filtered, displayed (possibly in different ways), etc. I would definitely go with Vue. From what I have heard, the most common argument for Vue (vs. Svelte) seems to be that the Vue community is much more mature, and you'll find a lot more ready-made stuff for it. And, of course, more people with the same issues (which, as a relative newcomer to the JS scene myself, I've found really useful). This is all very opinionated, but the way I see it, jQuery is great if you just want to sprinkle HTML with some added-on behaviour, while for bigger stuff it actually tends to get more complex than if you'd chosen a full-blown front-end frameworks in the first place. So again, it depends on what you're actually building πŸ™‚ If you do decide to go with Vue, for admin UI's in particular you might want to check out https://vuetifyjs.com. With Vuetify you'll have to sacrifice some freedom in terms of UI design, but once you get up to speed with it, it's pretty amazing β€” in many cases seemingly complex stuff gets done in a matter of minutes πŸ˜…πŸ‘Œ
  20. First of all: for feature requests you might want to open an issue at https://github.com/processwire/processwire-requests. This is how it'll have the best likelihood of gaining the attention of Ryan πŸ™‚ I do agree that a sufficiently complex and rapidly expiring initial key embedded within an URL should be enough, but saying that the verification key wouldn't add any extra security isn't, in my opinion, completely fair. The longer the key the more secure it should be, and a second verification method (particularly one that user has to enter separately) adds another layer of safety. Technically it could also a) force the user to actually read the message, and b) prevent attacks where the user is somehow fooled into clicking an URL β€” though I'm not sure how common attack vector this would be. The way I see it, current implementation trades some ease of use to some extra safety, and personally I'm fine with that: password reset process should be a relatively rare occurrence, and attacks targeting such features are a common problem. (But you do make a good argument here; perhaps this should actually be a configurable setting for the module?) Again I think this depends a bit on your of view: on one hand current implementation makes sure that if one just gains access to a reset link they won't be able to change the password (particularly if you ask them to confirm something other than the email field), but on the other hand some experts recommend that this step should occur before sending the reset message (exactly for the same reason β€” security). Seems like another potential module setting to me, perhaps even so that both options (confirmation before and confirmation after) would be available. Just a quick note on this one: you don't actually have to force the users to go through the password reset procedure. In a case like this it'd be relatively simple to set up a custom process to handle the initial password reset β€” create and send the links to your users and process them through your own code. I've done that a few times during large scale migrations, and it's not that hard to do β€” though in most cases I would still recommend going through the password reset feature. Personally I don't think that the process is that hard on users. Just an idea β€” again I get that you're hoping to change things in general, but if you need to get this done on a timely manner, it would probably be best not to wait for a core level change. Especially since it isn't necessarily a complete no-brainer how this feature should work πŸ™‚
  21. After reading and re-reading the posts here a few times, I must admit that I'm lost. What is the problem you're running into? πŸ™‚ I realize that this is an old topic, but... in what HTML markup exactly, and how (and where) are you trying to add that script tag? πŸ™‚ If you're editing a template file, you can just add in the script tag β€” just like any code. Or was your issue that the script itself is not working? If it's the latter case, please share the markup and the script so we can better figure out what's going on.
  22. This is fixed: in the latest dev version wire/config.php points to the HTTPS URL of the modules directory, and the modules directory also again accepts HTTP connections (which should guarantee backwards compatibility).
  23. Was actually going to suggest that perhaps the modal window could have both options, but this would be much better πŸ™‚
  24. Hey @montero4! Just to confirm: are you using the Blog module (https://modules.processwire.com/modules/process-blog/), or perhaps something else?
  25. Depends a lot on the use case: if you already know the title of the page you're going to pick (and only have a single item named like that), autocomplete is nice. Otherwise it can be pretty useless (as a selection mechanism): in some cases I've actually had to open a separate tab to browse to the page in the page tree just to find a name I can then type in an autocomplete field πŸ˜…
Γ—
Γ—
  • Create New...