Jump to content

teppo

PW-Moderators
  • Posts

    3,208
  • Joined

  • Last visited

  • Days Won

    107

teppo last won the day on February 5

teppo had the most liked content!

3 Followers

About teppo

  • Birthday 08/21/1984

Contact Methods

  • Website URL
    https://weekly.pw

Profile Information

  • Gender
    Male
  • Location
    Finland

Recent Profile Visitors

83,599 profile views

teppo's Achievements

Hero Member

Hero Member (6/6)

6.3k

Reputation

54

Community Answers

  1. Awesome — thank you! I'll definitely put this into use 🙂 Hard to say how common of a need this would be, but I wouldn't be against it (obviously).
  2. Just this week had to deal with the same thing on a site with 100+ translatable strings, many views reusing same translations, and three languages. Ended up splitting translations into a (static utility) class that has a string() method that returns the translation. So basically the same thing that Ryan has done here. Biggest difference is that since many of those strings in my case also exist in the admin as field labels, I added a fallback that first checks if a translation for current language exists, and then falls back to the field label if possible. I guess this confirms that I'm not doing anything too silly 😄 ... but on a loosely related note, if anyone has a good idea how to check if a string has been translated, I'd be happy to hear. I'm currently just comparing the source value to the return value and if it has not been changed I'll assume that a translation wasn't found. That's obviously a bit crude. Would be nice to have some way to check if the returned value from the translation method in core is indeed a translated version 🙂
  3. Very interesting concept, and works nicely! ... but I have to admit that I spent a few minutes trying to figure out how to actually view any content. Clicked the labels, nothing came up, clicked other labels, lines came up but still nothing else, etc. Would've given up if I hadn't known from the screenshots here that there is more to see. I get it now (you have to click those unlabeled sections at the outermost layer of the wheel; assumed at first that they were just a visual thing since there was nothing on them) but you might want to consider giving those sections some kind of label as well. Or add a help text or something. Just a suggestion 🙂 Anyway, always great to see projects that dare to be different.
  4. Thanks, Ryan; I see your point. I don't necessarily agree with all of it (apart from the front-end facing modules part, that I fully agree with), but I appreciate you taking the time to explain your view! Also, I'm clearly in the minority here with my opinions 🙂 One last point, though: When I hear someone describe vanilla JS as not fun or inconsistent, I do wonder if they might be, perhaps, remembering JS as it was a long time ago. Modern JS is at least as far apart from JS of 2006 (when jQuery was released) as PHP 8 is from PHP 4 (also from 2006). After being a heavy jQuery user for years I've been getting more into vanilla JS these past few years, and I must say that my impression of it has changed a lot. Anyway, just saying that if you've been on the jQuery side of things for a long time, giving vanilla JS a try may be a positive surprise. Of course if you're super into the jQuery syntax any difference may be a dealbreaker — and that's fine too 🙂
  5. It doesn't. Most users probably don't mind as long as it works. In that regard it is indeed great news that they are still going on. But does it mean that it is a good idea to keep relying on jQuery? Is it a good idea to use a framework that doesn't really add much to the mix anymore? I don't think so, but perhaps I'm wrong 🙂 The point I'm trying to make here is that yes, jQuery used to be important, but these days it's just another dependency that you can pile on top of your stack if you so choose. It essentially does the same thing as native API's, just with a slightly different (and non-standard) syntax. To me that doesn't seem like a great thing. If the general opinion is that jQuery is indeed the future and we should keep relying on it, then sure, let's keep it going. I'm just not sure what the actual benefit is, apart from the fact that it's what folks are used to 🙂
  6. I didn't mind the boilerplate required to add a new panel (especially since there is an example HelloWorld panel available), and it is definitely nice to have essentially unhindered access to native Tracy extensions, but it also wouldn't hurt to have a hookable method as suggested by Bernhard (if feasible). If adding new panels was that easy, it could be more tempting to add site-specific panels etc. 🙂 (Of course this should be an addition / alternative to current approach, not a replacement.) Just for context, here's the discussion that led to what we currently have:
  7. Makes sense to update to jQuery 4 once it's available and stable, but I must admit that when I read that article my first thought was "holy crap, they are still going on?" 🙊 Serious question to @ryan: what's your take on jQuery these days, do you still see it as something we will be, or should be, relying going forward? I'm not trying to push any agenda here, but I am wondering if you'd be open to perhaps starting to migrate more of ProcessWire's core code to vanilla JavaScript. I'm also not going to go into the "but what about Vue / React / Alpine / HTMX / insert-name-of-any-other-library-or-framework-here" topic at this point; that's a whole different subject. Also: all modern libraries are advocating the use of native JavaScript API's instead of "framework specific magic" anyway, so vanilla JS would be a good first step towards something new. In my opinion (which I've probably voiced here on the forums a few times already) jQuery is now largely obsolete. And I'm saying this as a former fan — it was amazing back in the days when native JS API's were very crude and lacking. Today it's more of a problem. For those that don't know what I'm speaking about, one example is the way jQuery handles events: the API is nice, but also hacky and non-standard, leading to the fact that in order to combine (standard) JS events with jQuery events you essentially need yet another library. (And vendor lock-in, intentional or not, is not a good thing.) Personally I find myself reaching for jQuery in pretty much one specific case: many third party plugins/libraries still rely on jQuery. This is less of an issue every year as devs keep moving forward, but there are still many popular plugins that do require jQuery. For every need there is a non-jQuery solution, but it can take a bit of work to find / migrate to. Some things are admittedly more difficult to replace, and one of those is jQuery UI. But since jQuery UI is already in "maintenace updates only" mode, replacing it is likely something that has to be done at some point. (Also... form serialization. That is something they did really well. And no, vanilla JS FormData is not a direct replacement 😅) Sorry for the long rant, but I just felt that this needed a bit of context. I for one would be happy to submit PR's etc. that would move us towards fewer dependencies for jQuery if that's something that'd be beneficial for the project. I believe it would be, but that's just me 🙂
  8. teppo

    CVE-2023-24676

    This is the part that I was most confused about. The post goes to detail about trivial stuff such as how to create a zip file, but then simply states that... They make it sound super easy, and obviously it is when you are both the attacker and the victim, but that has little to do with real world. Of course MITM is a serious threat and systems should be configured properly and users should be educated about risks of e.g. connecting via public wifis, but it's not something you can just pull off like it was nothing. And yes, any system that allows the user to directly execute code or upload files that are executed as code is technically "vulnerable" once you gain access to those features. That being said, I do see some potential for improvement here. For an example I think the default settings for moduleInstall should be as strict as possible, and I'm also wondering if ProcessWire could do light-weight scanning of obviously dangerous actions? Something like checking if an uploaded module/PHP file contains exec/eval/etc. or base64 encoded values, and at least displaying a warning to the user. Not sure if that's really feasible or particularly useful, though, and it could no doubt be circumvented by a targeted attack. Just a rough idea 🤷‍♂️
  9. teppo

    CVE-2023-24676

    Based on how they kept specifically mentioning the requests containing the download_zip_url variable and the relatively high score this CVE has (7.2 High) I was expecting that they'd found some major issue, or perhaps a way to circumvent normal core behaviour. But really it just seems like they figured out that if you are able to inject code into the system you can use it to do nasty things. There is one difference to the Tracy example, of course: in that case the administrator would have to install Tracy and then type in the command to the Console panel. If the attacker doesn't have superuser access but they know a system that matches aforementioned conditions, they could lure an existing superuser to install malicious code via the admin 🙂 -- I don't want to belittle any potential security issues, but it seems that this one is blown way out of proportion. I'm not familiar with the process used to validate and score CVE's, but it seems that they definitely err on the side of "always assume that reports are true, and always assume that the issue is as bad as it could theoretically be".
  10. teppo

    CVE-2023-24676

    A new vulnerability (CVE-2023-24676) was published last week, detailing how module install can be used to execute code and set up a reverse shell on a site. After going through the post that explains the exploit a couple of times I'm wondering if someone could confirm that I've got it right: First of all it requires that a) web server has write access to the modules directory and b) ProcessWire is configured to allow file uploads, right? The latter is by default true in debug mode, which is also mentioned in aforementioned post as one of the conditions. Built-in module downloading features check the moduleInstall setting (in ProcessModuleInstall class) and I couldn't find any way to circumvent them. For anything bad to happen, user with (presumably) superuser access must type in an URL of a ZIP file with malicious code, or someone must be able to intercept the request and change it. First part seems to be a non-issue, e.g. if a superuser really does that then there's very little that can be done to protect them, while the second part (to my understanding) sounds like it would be very unlikely and quite difficult, at least assuming that requests are passed through HTTPS. According to the post the PHP file in the zip is automatically executed by the system. I find this part a bit strange — I'm not exactly familiar with every involved piece of code, but it doesn't seem like ProcessWire should do that. On the other hand if the file in the package was a properly formatted module class, then this would be more likely, and again probably not something that can be prevented. So, in other words, it seems to me that this vulnerability isn't really a vulnerability — more like a way to use a built-in feature to do potentially harmful actions, of which users are specifically warned about in UI of said feature? Let me know if I got something wrong here, though. If anything, it seems to me that this is a good reminder that it is indeed dangerous to enable file uploads from arbitrary URLs or allow web server to write files that could be executed as PHP (or any other language for that matter, including JavaScript). Only thing that I think we could do better is to set those module file download settings false by default, instead of debug as they are now, just to be extra sure that a developer has indeed intentionally enabled them 🙂
  11. According to https://github.com/ckeditor/ckeditor4/issues/5510 it was indeed added to check if the installed version is up to date, but that's still unexpected and — in my opinion — just plain nasty. There should be absolutely no reason for CKEditor to "call home", except perhaps for those subscribing to their commercial LTS version. And if that feature was added just to push paid subscriptions to existing users once security issues are inevitably found from the free version, that doesn't make it any better. Thought about posting a question about that in the issue, but look like they've disabled commenting; doesn't seem like they're interested in open discussion. Migration to TinyMCE feels more and more like the right move 🙂
  12. That is a good point. Personally I like the point that they output vanilla CSS by default, since that's most likely what I'll be using, but it would make less sense if you're using Uikit or Bootstrap or something like that. Tailwind export is probably the easiest example, since it's (mostly) just 1:1 mapping CSS styles with utility classes 🙂 Here's a pretty simple button element exported as HTML + Tailwind directly from Figma: <div class="w-52 h-[58px] px-6 py-4 bg-stone-950 rounded justify-center items-center gap-0.5 inline-flex"> <div class="text-white text-base font-semibold font-['Roboto'] leading-relaxed">Tue toimintaamme</div> </div> It's not perfect: for an example there's no way to tell Figma that I've mapped Roboto with the "sans" font so it should use font-sans instead, for some reason there's an extra div that shouldn't be necessary, and (at least in this case) it didn't understand the context so the button is not actually a button. But on the other hand this is not that far from what you might use in an actual project. (In this particular project I've got a button CSS component that I would rather use, but generally speaking in Tailwind sprinkling utility classes in markup is the preferred method...)
  13. Figma generated code doesn't really feel like it was intended to be exported and used as-is, especially for large chunks like that. I do find it pretty good for other use case, though; for an example you can quickly glance over the values instead of finding them from different inputs all over the GUI. And I'll admit that I've copied a shadow or gradient every once in a while as-is from Figma 🙂 I'm looking at one project right now, and for color theme it is actually using CSS variables, which takes care of some duplication. I don't know why it's not doing the same for font families, though. And seems to me like it should be able to create a separate element (class) for each text style and then refer to those somehow 🤔 Apart from native Figma tools, Anima (Figma plugin) seems decent. I've not used it for real projects myself and probably won't for the foreseeable future, but I did a quick test with it some time ago and it seemed... relatively good. And it's a nice touch that it can export React/Vue components.
  14. I get that the gist of this thread is "WP bad", but to be fair I've ran relatively often into the opposite issue in ProcessWire: an image or file that should've been uploaded once and then reused is instead uploaded to a whole bunch of separate pages, using loads of unnecessary disk space. ProcessWire doesn't by itself create a lot of unnecessary variations, but it is not uncommon occurrence either: years of code changes combined with badly configured image fields (no limit for image dimensions) can lead to major disk bloat. Worse yet is when someone decides that a file/image that is separately uploaded all around the place now needs to be updated everywhere. Oh the joy! Long story short: there are cases for and against both central media/asset management and page based media/asset management, neither are perfect. Now what is indeed suboptimal is the way WordPress handles variations: they need to be globally registered, are created on upload (whether you need them or not), and won't be (re)created automatically if registered or changed later. This can absolutely lead to unnecessary disk usage, and on the other hand means that you may not have the variation you were looking for available, or it may not be what you expected it to be. But again, each approach/architecture has upsides and downsides 🙂 -- By the way, I'm not generally against bashing [insert a CMS or any other product here] or venting frustrations about it, but I do think we should try to be fair. WP gets a lot of bad rep for a good reason, there are definitely issues and shortcomings, but it also gets blamed for legacy/aging custom (site/theme specific) code, overuse of third party plugins, outdated third party plugins, etc. None of these are core issues, and it's not really fair to blame them on WP 🙂
  15. Parts of it, at least, yes! I've had for a very long time on my todo list a related idea; basically something like the https://translate.wordpress.org/ portal for WordPress. Though I didn't honestly even consider using pre-built solutions. I don't say this lightly, but this is an area where WordPress is way ahead ProcessWire, in my opinion. Just a few reasons why I think their system is so good: It's a shared, easy to use, web-based, non-developer friendly system. Whether I'm a contributor or someone wanting to install a translation for a plugin, I don't need to figure out how author of plugin x wants to handle their translations, and I also don't need to know or figure out how to create a GitHub account, open pull requests, etc. This point alone is a major benefit and lowers the bar for contributing 🙂 Just for the record, many plugins still bundle translations with the source code. So yes, both systems can co-exist. Anyone can contribute without core/theme/plugin author(s) having to do anything. I for one have access to Finnish translations for a few plugins. Permissions are handed down by general translation editors for the locale, which is much easier than having to contact individual plugin authors who may or may not be around and active, and may or may not be interested in bundling some language they have no personal interest in. Once a locale has enough coverage, it automatically becomes installable via the admin and via WP-CLI. Personally I use WP-CLI for managing site translations, as it makes things a lot easier to automate. Installing and updating translations is literally one command away, which — as someone who manages quite a few sites — is a big bonus. This, of course, only works for plugins that have been translated this way. Not all have. It's not a perfect world. Finally, the system handles versions properly. For an example if I wanted to submit a correction for the Finnish translations for ProcessWire version 3.0.184, there's no easy way to do that. Maintainer of the Finnish translations repository could set up separate branches or some other way to handle it, but this would be a case by case thing, and there's no guarantee that the language pack maintainer is interested in such a thing. In the past I've also contributed via Launchpad, which (at least back then) was essentially the same thing for free / open source software, and worked really well in my opinion. Anyway, I'm still interested in this idea, but have not had time to pursue it myself. Maybe one day, unless someone else solves it properly before me 😉 In my opinion it is a viable idea, but there are many questions to answer, and quite a few of those are not straightforward. Also I believe that in order to gain traction this would need to be somehow integrated into our current translation tool(s) and it shouldn't be too opinionated (for an example I personally would prefer it to not update anything completely automatically, as was suggested here earlier.)
×
×
  • Create New...