Jump to content

teppo

PW-Moderators
  • Posts

    3,219
  • Joined

  • Last visited

  • Days Won

    109

Everything posted by teppo

  1. I'd love to suggest other things as well, but for now I'll just say that this is also my experience. Sorry in advance if this turns into a rant, but I feel that this is an important topic 🙂 Past few years we've shifted our focus so that now we mainly use ProcessWire for sites with heavy focus on application like features and structured content, while "regular websites" are more often built with WordPress. There are cases where ProcessWire is stronger, and it can be used to build flexible, content block based sites using something like Repeater Matrix, but to be fair Gutenberg (which I/we use solely, no other page builders) is on another level when it comes to built-in flexibility and WYSIWYG. With one exception: you can't have multiple "Gutenberg fields" on single page, which can, in fact, be a pretty big bummer in some cases; and that could also be a potential benefit if we did have some sort of block builder in the core. (... and if ProcessWire, on a core level, wants to focus more on directory / application type sites, there's nothing wrong in that either. It just means that we, as a group of ProcessWire developers and enthusiasts, will be "losing" a large — and likely increasing — amount of potential clients and projects for other systems.) The work done by Bernhard and jploch is fantastic, but for me the biggest question mark is probably that these are not core features, meaning that they are not something that is "officially supported" by the core / core team. They are also not free / open source software, which means that the community directly participating in their development is not really an option, in my opinion. I'm not sure what the best solution, especially since this is clearly not a common need/requirement for Ryan, but I do hope that we could eventually have some level of support for this at the core — even if it's not "full-featured", but rather a framework that can be expanded / built on top of. Using Gutenberg as an example: I don't have a real figure, but I can tell that a team has worked on it for many years now, and continues to do it on a daily basis. It's not realistic to assume that a single developer could truly compete with that. And one thing I've learned about page/block builders is that there's a lot of nuance and the architecture is a major question that could make or break it, so doing it without solid understanding of what the results of each choice is way down the pipeline would be a huge gamble. (In case of Gutenberg the architecture is a hot mess: there are no dedicated data structures, and they keep changing and breaking internal code all the time. But, again, they have enough resources to handle that, and the project has so much momentum that while developers may complain, eventually they'll have to go with the flow.) As for Ryan's point about preferring to "avoid features that blur the line between content and style or front-end and admin", which I assume was related to this request (to some extent at least), I'm sure there are ways to handle content block GUI in the admin without putting too much focus on how they look like on the front-end. E.g. tje editing interface could be more like a wireframe with some similar structure than "the final product". Front-end editing is an option, but... I must admit that I like the "middle ground" that Gutenberg has, where you're still editing content in the admin. Obviously introducing front-end styles for the content in admin is not a nobrainer, which is why many sites — in my experience — won't even aim for fully stylized (custom) blocks in the admin. WYSIWYG is a big topic in itself 🙂
  2. And here I was thinking that this is so useful that it should be a core feature 🙂 Anyway, just wanted to say that I absolutely love the concept of this module. In fact both Custom Logs and Logs JSON Viewer are brilliant additions!
  3. I’ve not touched this module in years. I’m not surprised that the GUI is a little wonky. It was never tested on the UIKit admin theme, let alone recent jQuery versions ? That being said, thanks for testing and identifying the issue, looks like an easy fix. As for alternatives, there are of course third party tools (at least for public content), and there’s also Verify Links from Robin: I can’t say for sure how much time and effort I’ll be able to put into this module, so I’d suggest checking Robin’s module out ?
  4. Whether or not the system is built on top of a framework is, in my opinion, largely irrelevant. Or perhaps it would be better to say that "it is impossible to guess if and how it would've mattered in the big picture". Call me cynical, but dependencies are never free. Each adds weight to the codebase, requires upkeep and maintenance (sometimes including major updates or rewrites), and increases potential attack surface. Also many dependencies — and especially frameworks — bring in their own way of doing things, and since ProcessWire's architecture (hooks, data structure, etc.) is really a major selling point for the system, using a framework could've had a massive impact on that. Part of the reason why ProcessWire is such a brilliant system could very well be due to it not being powered by a framework itself. This means that every decision could be made without considering how that would fit the framework. What is also interesting, in my openiin, is the framework landscape itself. Back when ProcessWire 2.0 was launched, Laravel — now considered the latest state of the art PHP framework — wasn't even around yet. Zend Framework was probably the biggest name back then, or at least the one that most serious developers considered "most likely to thrive and stay around"... yet it was discontinued. Had ProcessWire gone with the "safe bet", that would've meant a big rewrite later, or alternatively staying on a platform that is merely a shadow of its former glory. Long story short, I think Ryan made a good choice ? Don't get me wrong, though: I'm a big fan of the Composer ecosystem — almost all of my modules are available as Composer dependencies, etc. And, in my opinion, ProcessWire actually integrates quite nicely with external dependencies. Since HTTP clients were mentioned, I'll use that as an example as well: in some recent projects I've used Guzzle together with ProcessWire. I may not be able to (easily) swap the client used by the core itself, but I've yet to come across such a need anyway. Of course this comes with a cost: I recently had to migrate one project to a new server simply because a third party dependency decided to drop PHP 7.4 support. In a minor version, because why the heck not. Not that it's a bad thing necessarily to bump up the PHP version, but having to do that sort of thing in a hurry just because I prefer to use a recent and patched version of a dependency is just bollocks. This is starting to get a bit rambly, so I'll just leave it here.
  5. There's no such thing as an ignorant question, but in this case I would probably lean towards "unnecessary headache" ? If ithe goal is to use some data from Strapi and combine that with some content produced in ProcessWire, this might make sense. E.g. the data from Strapi would only cover part of the project. But if the client wants to continue to manage all their content in Strapi and you'd just be using ProcessWire for the front-end, this would mean that you'd be mitigating much of what ProcessWire has to offer. Not to mention that it might be a bit of work to make the systems run smoothly together, and when things inevitably change in the future, you'd be doing every update to the content structure twice: once in Strapi, and again in ProcessWire. I'm not familiar with Strapi, but I'm pretty sure they have a decent API already (considering that it's a headless CMS that's kind of their bread and butter) so personally I'd consider building the front-end using something else. Laravel might be a decent PHP choice, but there are many other solutions as well. Most commonly folks seem to combine Strapi and similar headless systems with some JS framework, e.g. https://strapi.io/integrations/vuejs-cms. Anyway, that's just my opinion ?‍♂️
  6. Reactions is a module that collects reactions for pages from site users/visitors based on a click of a reaction button. It's basically the same thing as those "did you find the information you were looking for" thingies you see on some sites. An example of what the buttons might look like: There is also a very simple process module that displays pages along with their reaction counts for each enabled reaction type. GitHub repository: https://github.com/teppokoivula/reactions Modules directory: https://processwire.com/modules/reactions/ Needed this for a project and was kind of in a hurry, so it's not super polished, but seems to work well for basic use cases. One thing that's kind of fun (or scary) about this module is that it modifies the structure of the reactions database table automatically based on active buttons; this is done using ProcessWire's built-in features ? Getting started You can install the module the usual way; clone or download the code, or install via admin. Or via Composer: composer require teppokoivula/reactions The easiest way to define available buttons is via site config: $config->reactions = [ 'reaction_types' => [ 'like' => [ 'title' => 'Like it', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="M720-120H280v-520l280-280 50 50q7 7 11.5 19t4.5 23v14l-44 174h258q32 0 56 24t24 56v80q0 7-2 15t-4 15L794-168q-9 20-30 34t-44 14Zm-360-80h360l120-280v-80H480l54-220-174 174v406Zm0-406v406-406Zm-80-34v80H160v360h120v80H80v-520h200Z"/></svg>', // optional attributes, either as an associative array or as a string, e.g.: // 'attrs' => [ // 'data-some-attr' => 'value', // ], // 'attrs' => 'data-attr="value"', ], 'love' => [ 'title' => 'Love it', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="m480-120-58-52q-101-91-167-157T150-447.5Q111-500 95.5-544T80-634q0-94 63-157t157-63q52 0 99 22t81 62q34-40 81-62t99-22q94 0 157 63t63 157q0 46-15.5 90T810-447.5Q771-395 705-329T538-172l-58 52Zm0-108q96-86 158-147.5t98-107q36-45.5 50-81t14-70.5q0-60-40-100t-100-40q-47 0-87 26.5T518-680h-76q-15-41-55-67.5T300-774q-60 0-100 40t-40 100q0 35 14 70.5t50 81q36 45.5 98 107T480-228Zm0-273Z"/></svg>', ], 'haha' => [ 'title' => 'Haha!', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="M480-260q68 0 123.5-38.5T684-400H276q25 63 80.5 101.5T480-260ZM312-520l44-42 42 42 42-42-84-86-86 86 42 42Zm250 0 42-42 44 42 42-42-86-86-84 86 42 42ZM480-80q-83 0-156-31.5T197-197q-54-54-85.5-127T80-480q0-83 31.5-156T197-763q54-54 127-85.5T480-880q83 0 156 31.5T763-763q54 54 85.5 127T880-480q0 83-31.5 156T763-197q-54 54-127 85.5T480-80Zm0-400Zm0 320q134 0 227-93t93-227q0-134-93-227t-227-93q-134 0-227 93t-93 227q0 134 93 227t227 93Z"/></svg>', ], ], ]; ... though you could also add them programmatically, e.g. if you wanted to manage them via admin: $wire->addHookBefore('Reactions::setReactionTypes', function(HookEvent $event) { $reaction_buttons = $event->wire()->pages->get(1)->reaction_buttons; if ($reaction_buttons->count()) { $reaction_types = []; foreach ($reaction_buttons as $reaction_button) { if (!$reaction_button->title) continue; $reaction_types[$reaction_button->name] = [ 'title' => $reaction_button->title, 'icon' => $reaction_button->icon && $reaction_button->icon instanceof Pageimage ? $reaction_button->icon->filename : null, ]; } if (!empty($reaction_types)) { $event->arguments(0, $reaction_types); } } }); The module has basic styles and scripts bundled in, though you'll have to load them yourself: <link rel="stylesheet" href="<?= $config->urls->Reactions ?>styles/reaction-buttons.css"> <script src="<?= $config->urls->Reactions ?>scripts/reaction-buttons.js"></script> ... and then call the render method to render the buttons in your template file(s): <?= $modules->get('Reactions')->renderReactionButtons() ?> For those interested in doing stuff like displaying something based on the answer, bundled JS triggers an event that you can listen to: document.dispatchEvent(new CustomEvent('reactions-updated', { detail: { pageID: pageID, reaction: reaction, }, }, { bubbles: true }));
  7. Hey Ivan, Sorry for the delay. In all honesty: usually render() is the one you want. There are very few cases where init() is better, or necessary for that matter. Behind the scenes init() is triggered as soon as a Controller class instance is created; at the end of the __construct() method. Meanwhile render() is only called when a page is, indeed, rendered. This means that render() gets called one time for each rendered page (e.g. in case you're rendering multiple pages within single request), while init() is called for each item as soon as their controllers have been instantiated. Personally I've ended up using render() pretty much all the time ? There is no built-in solution for this, but if you want to stop rendering the page as soon as you detect (in init()) that you don't want to render it, you could e.g. trigger a redirect, or perhaps call wire404(). Now, if you do use this solution, you'll want to make sure that it's not a "page being rendered within another page" type of situation, as that would be pretty problematic. Alternatively you might be able to call $this->setView() to override the default view file to something specific to an error scenario. I'm not 100% sure of this though, as its not really something I've every done ?
  8. 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).
  9. 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 ?
  10. 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.
  11. 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 ?
  12. 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 ?
  13. 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:
  14. 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 ?
  15. 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 ?‍♂️
  16. 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".
  17. 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 ?
  18. 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 ?
  19. 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...)
  20. 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.
  21. 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 ?
  22. 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.)
  23. 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". Makes sense. Loosening the permissions a bit in development doesn't sound too bad, and the API option sounds like a reasonable fallback ?
  24. 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. Was just about to ask... ?
  25. 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 ?
×
×
  • Create New...