teppo

3 hours ago, ryan said:

@teppo Not very straightforward, but here's a function that would tell you whether or not a translation exists for the given phrase in the given file, in the current language.

Awesome — thank you! I'll definitely put this into use 🙂

3 hours ago, ryan said:

Maybe we need a dedicated core function for it?

Hard to say how common of a need this would be, but I wouldn't be against it (obviously).

On 3/8/2024 at 10:46 PM, Denis Schultz said:

I wanted to ask how some here deal with repeated translation strings, and then I got my answer in this site profile ^^

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 🙂

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.

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 🙂

7 hours ago, Robin S said:

I don't see how its use in the PW core disadvantages users in any way.

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 🙂

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:

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 🙂

22 hours ago, BitPoet said:

When you can intercept a communication to that level and modify the message body, you could just forge the necessary requests, supply them with the intercepted session information and use the built-in module upload functionality.

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

Quote

When intercepting the request using Burp Suite [...]

To inject the malicious code into the ProcessWire application, I intercepted the plugin installation request once again. This time, I inserted the URL of the VPS containing the “plugin.zip” file with the malicious “pwn.php” code.

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

8 minutes ago, Robin S said:

Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel.

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

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 🙂

Quote

I did also try to upgrade CKEditor to the latest version (which is also the final open source version of CKEditor 4), but found it was making outbound http requests to ckeditor.com

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 🙂

1 hour ago, da² said:

The box I took as example is just a bit of UIkit configuration in my project, mainly overriding UIkit variables. Depending of CSS framework used it will be different.

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

17 hours ago, da² said:

On my previous project, a designer created a template on https://www.figma.com/. You can export design to CSS, I add a look at this code and it's a terrible thing. 😅

Everything is absolute, font-family and other attributes are duplicated everywhere... There's almost nothing to keep in the final code.

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.

8 hours ago, FireWire said:

I think that WP's central media library lends itself to massive amounts of unused images because they are uploaded and then associated with pages, the opposite of what PW does by associating images at time of upload. It requires a lot of manual maintenance. 

I'd rather a user replicate an upload on multiple pages than rely on a central media manager that requires manual deletion when an image isn't needed anymore. A user won't do it, and shouldn't have to.

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 🙂

On 12/11/2023 at 5:53 PM, MrSnoozles said:

In general: would that something you would consider useful? If so I could try implementing a POC when I find the time.

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

2 hours ago, bernhard said:

I have not tried to be honest, but I don't see a reason why it should not? Could you give me some context to think about it? What would you want to do?

Files are secured if they are on a page that is not viewable by general public, and — as far as I remember correctly — the core has some Repeater specific checks for file permissions, since Repeater pages live outside the normally viewable part of the site. If I use a RockPageBuilder field on a page that is publicly viewable, the files should be all available as well, but if I use it on a page that is not available for a public, those files should only be available for users with access to that specific page (via template access settings, hooks, etc.)

RockPageBuilder sounds like it could be a good solution for a project I'm starting soon, but this site will have a members only section for logged in users, and thus this is one thing that would need to work "as expected".

2 hours ago, bernhard said:

Technically you can place those files wherever you want. The module has an API to load those blocks, eg $pagebuilder->loadBlocks('/path/to/dir'); The easiest way to use it is to stick with the defaults, because then everything happens automatically and you don't need to understand the module's inner workings.

Makes sense. Loosening the permissions a bit in development doesn't sound too bad, and the API option sounds like a reasonable fallback 🙂

This looks very tempting!

A few technical questions, if you don't mind:

• Where does RockPageBuilder store the block pages?
• Somewhat related to the previous point, does RockPageBuilder work nicely with secureFiles?
• In your demo I noticed that when you added a block, related files were automatically added to the templates directory. Is this necessary, or is there a way around it?
  • In my case this would be a no-go, due to various reasons — one being security concerns, while another is related to the load balanced setup we use to host sites, where code on each individual machine is practically considered immutable.

Quote

No. RockFrontend must be installed so that RockPageBuilder can automatically load various assets for frontend editing. You can still develop your frontend however and with whatever you like! You can use markup regions. You can use the wireframe framework.

Was just about to ask... 😅

On 10/31/2023 at 9:05 PM, BitPoet said:

If you don't mind me asking: which IdPs have you had success with, and did you have to dabble with advanced settings to get things up and running? (If you don't want to or can't answer that, I'll understand).

Only used OneLogin so far. It's been a couple of years since I set this thing up, but as far as I can remember there was no need to tweak anything in advanced settings 🙂

Just to confirm: I've got a php-saml based setup running (via in-house PW SAML module, which is loosely based on https://github.com/adamxp12/ProcessWire-SAMLAuth) and only requirement there is onelogin/php-saml ^4.1 🙂

Anyway, it's good to have an up to date SAML module available, so thanks for sharing!

Skip Inputfield Label is a tiny module that makes the skipLabel Inputfield option configurable in the admin interface.

I'm not entirely sure why this option is not available by default, but I've found it useful for some use cases, as it can reduce the clutter in admin. That being said, it is also potentially problematic, especially when using options that completely remove the label — this is usually a horrible idea due to the accessibility issue it creates.

This module is not widely tested yet, so please be careful. Technically it should work with FormBuilder as well, though again that is not something I have tested much.

• Modules directory: https://processwire.com/modules/skip-inputfield-label/
• GitHub: https://github.com/teppokoivula/SkipInputfieldLabel
• Composer: composer require teppokoivula/skip-inputfield-label

There are some pointers here, probably a good place to start from (if you haven't read it yet): https://processwire.com/docs/security/file-permissions/

Quote

Or should it be www-data user owning writable folders and linux user owning the remainder?

This is what I tend to do.

Form Builder Default Data is a super simple module that adds (via module config settings) the ability to set a default value used as "import data" when creating new Form Builder forms. Form Builder already provides an export option for created forms and an import field when creating new forms, so the only thing this module does is hook after form creation and, in case import data was not provided, set it to the default value instead.

The original use case for this module was for a client site where each form should have a consent checkbox with predefined text. With this module the field is always added, but it can be easily removed if a specific form doesn't need it. If updates are needed later they need to be done on a form-by-form basis (or directly via API or SQL), but in this particular case that is an acceptable tradeoff.

Anyway, I hope someone else will find this module useful as well 🙂

• Modules directory: https://processwire.com/modules/form-builder-default-data/
• GitHub: https://github.com/AvoineOy/FormBuilderDefaultData
• Composer: composer require avoineoy/form-builder-default-data

This sounds a lot like the issue in https://github.com/processwire/processwire-issues/issues/1802, especially since @ryanspecifically mentioned fixing an issue where title!= was misbehaving by finding too many results.

"If it works, don't touch it" 🙂

Seriously speaking though, this module works well and does what it needs to do. So yes, if you want to restrict access by branch then it is a good option, regardless of which core version you are using.

Version 1.0.0 of the MarkupMenu module released: https://github.com/teppokoivula/MarkupMenu/releases/tag/1.0.0.

This release includes a relatively minor, but also potentially breaking change: new argument $root was added to the MarkupMenu::renderArrayItem() method, between some of the existing params. Since this method is hookable this could be a problem for existing code, so I figured it was best to increment major version.