Jump to content

teppo

PW-Moderators
  • Content Count

    2,575
  • Joined

  • Last visited

  • Days Won

    66

Posts posted by teppo


  1. 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 🙂

    • Like 3

  2. 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 🙂

    • Like 3
    • Thanks 1

  3. 1 hour ago, Andy said:

    in _head.php was

        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <link rel="icon" href="/wire/Favicon.ico" type="image/x-icon" />

    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.

    • Like 2

  4. 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!

    • Like 1

  5. 13 minutes ago, OllieMackJames said:

    What is it in Hanna Code that triggers WAF, any ideas?

    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.

    • Like 2

  6. 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?

    • Like 3

  7. 10 hours ago, daiquiri said:

    But when I get a response like "what you're trying to do doesn't make sense" and that "you shouldn't ever have to change the home page because it's sacred" - when I'm requested by a designer and a client to do exactly that - add an entirely new home page, and use the current one as a child of that, moving the entire tree down the hierarcy - then all I can say is principles are nice but reality is not always inline with an ivory-tower approach to things, unfortunately.

    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 🤷‍♂️

    • Like 7
    • Thanks 1

  8. 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... 🙂


  9. On 2/6/2020 at 12:11 AM, Mikie said:

    Cheers! I am storing magazine style story credits (role, name, website url etc) in the Table. I feel that since Table only accepts text based fields this is an ok candidate for indexing. Can try to hack away at your module myself for now, no rush.

    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 🙂

    • Like 2

  10. 21 hours ago, Mikie said:

    @teppo I don't think this is to with my setup. I have tried 3 x different character sets and encodings, all throwing errors. In particular... if I dump the result of processIndex() just before returning it, with that "à" character it is getting encoded as \xc3 when it should be \xC3\xA0. You can check this here: https://mothereff.in/utf-8.

    I don't understand enough about how you are prepping the data before saving the field, but this I think is an issue with multibyte substrings.

    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.

    • Like 1

  11. 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  😉

    • Like 3
    • Thanks 1

  12. 22 hours ago, dragan said:

    But maybe helpful if you have a lot of traffic, and want to reduce "behind-the-scenes" queries.

    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 😅

    23 hours ago, uncle_bobson said:

    My confusion was really about howto use vuejs with processwire. As both of them generate the html code for a page, they would be stepping on each other toes.

    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 😛

    • Like 3

  13. 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" ✌

    • Like 5

  14. 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 🙂

    • Like 1

  15. 23 minutes ago, bernhard said:

    Yeah, it's icons with hover text (title attribute) - but the screenshot program closes the tooltip before it takes the screenshot...

    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 🙂

    23 minutes ago, bernhard said:

    Actually it doesn't matter too much if it's icons or text - what is really different now is that I changed the name of the first checkbox from "fullday" to "hasTime". This is now consistent with the second checkbox named "hasEnd" and it is more intuitive for the user I think. Check the checkbox = show time inputs, uncheck = don't show time inputs. Before it was the other way round: Checkbox checked meant fullday, meaning that the time input was hidden. The second checkbox worked the other way round: Checked = show inputs, unchecked = hide inputs.

    This makes sense 🙂

    23 minutes ago, bernhard said:

    I'm happy to get suggestions how to call those two checkboxes...

    1. Show time input?
    2. Show end input?

    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 🙂

    • Like 1

  16. 59 minutes ago, Jens Martsch - dotnetic said:

    The hook from @elabx is really overkill and modifies the page, which is not needed.

    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 🙂

    • Like 5

  17. 2 hours ago, bernhard said:

    Little improvements to the input:

    tDlJJY4.png

    1) Checkboxes do now show an icon. I think that's a lot more intuitive!

    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.

    • Like 3

  18. 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) 🙂

    • Like 3

  19. 7 hours ago, manlio said:

    I have already build a "reserved area" for logged users on my PW website some years ago. I developed the "reserved area" using front end tools (Jquery and HTML) and the users don't see PW admin backend.

    Now I wanna extend and rebuild with modern tools this "reserved area" where users can modify their personal data, request certification cards for their students, publish courses, ecc...

    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.

    • Like 3

  20. 1 hour ago, manlio said:

    I know about Vue boilerplate and I have already searched the forum, but I have still doubts if it worths using something new over Jquery or if it is a waste of time in my case 🙂

    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 😅👌

    • Like 6
×
×
  • Create New...