teppo

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.

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 ?

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

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 ?

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

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

Here's a tiny module that I originally built for my own needs, but figured that someone else might find it useful as well: Textformatter Iframe Embed. It is a textformatter that (by default) turns this: <p>iframe/https://www.domain.tld/path/</p> ... into this: <iframe class="TextformatterIframeEmbed" src="https://www.domain.tld/path/"></iframe> Embed tag (iframe/) and iframe tag markup can be customized via module configuration screen.

I'm assuming that this problem was resolved already? Just in case: sounds like your home page wasn't throwing Wire404Exception "properly", e.g. providing Wire404Exception::codeFunction as the second argument or by calling wire404() ?

@szabesz, this should be possible with the latest version of the module. There's a new hookable method ProcessChangelogHooks::getPageEventDetails: $wire->addHookAfter('ProcessChangelogHooks::getPageEventDetails', function(HookEvent $event) { // getPageEventDetails can return null to prevent saving duplicate entries if ($event->return === null) return; $event->return = array_merge($event->return, [ 'Custom key' => 'Custom value', ]); });

Since classes/HomePage.php is part of the default site profile (blank profile) for recent ProcessWire versions, this makes it sound like the site might've been updated and possibly reinstalled. Would be interesting to know what those new files in wire were, e.g. if they were also files added by an update. Same goes for those new files in root dir as well. The site shouldn't update on its own, of course, so that still doesn't explain what might've happened in the first place. Your site didn't have install.php available, by any chance? That, combined with write permission for the web server user, could be one potential gotcha. This sounds like something that @ryan might want to look into, just in case. With the information we currently have available it is not possible to figure out much more.

The symptoms make it sound like your .htaccess file is somehow erroneous or Apache is not using/processing rules from it correctly. I would start debugging from there. You could, for an example, try to access one of the files that are normally protected by .htaccess rules, just to see if those rules are working as expected. (Root URL working properly is a typical sign of this as well: PHP is working and requests for the index.php file are apparently being processed, but .htaccess rules are not passing requests for non-root paths to it.)

Only solution I can think of right now would be handling cookie check server-side, which in most cases is honestly waste of time and resources. My solution is to leave noscript versions out, and use JS similar to what PrivacyWire (and probably all other sensible tools) do: by default the script is disabled (e.g. has type="text/plain" or something along those lines) and only after consent has been given that gets swapped with actual type.

As a free solution for ProcessWire I would definitely recommend PrivacyWire. In my opinion it is the only viable solution at the moment. When that's not an option or more automation is needed, we tend to use Cookiebot. It's a paid service (they do have a free tier for small scale and limited requirements), but there are a few things that can make it worth the cost: It scans the site (as you mentioned) automatically and creates a list/table of used cookies, as well as identifies any cases where cookies are set without prior consent. At least here in Finland a list of cookies used on a site — including whether they are first or third party cookies, what they are used for, and for how long they are stored — is required. While one can of course keep such a table up manually, well... let's just say that especially for large and media-rich sites it's a whole lot of work. It has an automatic block mode that at least tries to automatically prevent the browser from loading anything that can set cookies. With PrivacyWire (for an example) you'll have to modify the markup of embedded script tags, iframe elements, etc. in order to load them only after consent has been given. It automatically generates and stores per-user consent history. At least here in Finland that is a necessary thing — site owners must be able to produce proof that the user has indeed given consent to storing data, and a separate registry is a must (said proof has to be available even if the user has cleared their cookies, localstorage, etc.) With paid plans it is very customizable. For an example we use a modified version of generaxion/cookiebot-accessible-template, since many of our sites need to be accessible. There are other services that do similar things, and I believe that some are cheaper than Cookiebot, but I have not had a chance or any need to properly dig into said other services. I'm only familiar with official guidelines and legislation as it has been implemented here in Finland, and also IANAL. Even with GDPR the actual implementation (and how that implementation is interpreted by officials) can vary from country to country ?

As someone who has spent considerable time dealing with similar issues, submitting error reports and PRs, etc. in the context of WordPress plugins, I can say that it's simply a general issue with dependencies. Popularity of the CMS matters very little, if at all. Relative popularity of the module/plugin matters more, though even that is not a 100% guarantee. You can avoid some of this by only using the dependencies you truly require, and choosing the ones to use carefully: see if they are actively maintained, whether that is by regular code updates or via the support forum. Only using the dependencies I truly require, and choosing the ones to use carefully ? There's no silver bullet here. If the module author is still active you can submit error reports via support forum and/or GitHub. If the author is no longer active, someone (including you) could fork the module and make fixes there, but unless new maintainer is going to really commit into maintaining the module, it's not a good long term solution. For modules that are no longer actively maintained, my recommendation would be to move on — find something else that gets the job done. Or better yet, don't use a module. Again, you should only use the modules that you truly need. Alternatives for the modules you've mentioned: Instead of MarkupSEO you could look into Seo Maestro, but since the author (Wanze) has stated that they are no longer actively involved with ProcessWire, it's questionable whether this is a good long term solution either. We use Markup Metadata, which does at least some of the same tasks; it's also less involved/opinionated, which means that it's easier to maintain. Instead of AllInOneMinify I would really recommend looking into ProCache. It's not free, but if it's for a commercial purpose (or long term personal projects etc.) it is — in my opinion — well worth the cost. It also does a lot for your site's performance that AllInOneMinify won't do.

Yes. Current approach makes use of ProcessWire's database export feature and I'm not sure if it can do this (from what I can tell this is not really what it was meant to do; it was rather intended to store the dump "permanently"), so this might need to be a different command. Just like flydev mentioned above (native:restore). Personally I don't see much reason to use the ProcessWire db export method in this context, unless it does something special that mysqldump can't do (?). Various reasons for this. Resetting passwords is one, but I've also had to remove users matching specific conditions or temporarily disable their accounts, update categories for posts (e.g. a main category is removed and all posts that belonged to it need to be connected to a new one), automate some content modification for a number of pages matching specific criteria, etc. In WP it's not as easy to create "bootstrap scripts" as it is in PW, so WP-CLI is (in my opinion) often the easiest way to do any sort of bulk edit ? This is where differences between WP and PW matter. WP has a built-in cron task queue: the core maintains a list of registered tasks (some from core itself, others registered via hooks from theme(s) or plugins). Each task has a set recurrence (interval), a precalculated time for next run, and hook function to trigger when the task is due. WP-CLI can be used to trigger a specific task, run all tasks that are due now, etc. By default tasks are executed "lazily", similar to what ProcessWire does when using Lazy Cron, but typically you would not want to rely on that or slow down page views for regular users. Instead you'd set up a real cron job to run e.g. once per minute. That cron job then executes "wp cron event run --due-now --quiet". I don't say this often, but in this area WP is — in my opinion — ahead of PW. The cron setup makes a lot of sense, and it's really easy to keep track of active tasks ?

Fair ? If PHP has write access to directories containing executable code, this opens a huge can of worms: a malicious or vulnerable module could allow attackers to write code and wreak serious havoc on the target system. Same thing could happen if there's a flaw in site code that allows attacker to write or download their own executable files. You could argue that a malicious or vulnerable module could cause similar problems anyway, but in my experience it is often easier to slip in code that writes code than code that does evil things. At the very least it's another attack vector. I'm aware that even the installer suggests that we allow PHP to write to the modules directory, but in my opinion that should not be done unless absolutely necessary. And I have yet to come across a situation where that would be the case ?

Flushing caches and rewrite rules after each deploy Exporting database from production and importing it locally (sometimes, very rarely, the other way around) Editing (and sometimes just listing and filtering) users, posts/pages, rewrite rules, plugins... Managing (listing and running) registered cron jobs Managing translations Those are the most common things I use it for, ordered from most common to least common ? Looking at the commands currently available for RockShell, "db:pull" and "db:restore" seem like they could be most useful for me personally. I'm not entirely convinced about the method used there, though, considering that it needs to store temporary dump file(s) on the disk. Seems to me that using mysqldump and redirecting the output to local disk has certain benefits over this — such as eliminating the need for temporary files, and thus also eliminating any chance of multiple simultaneous pulls causing conflicts. "pw:users" could be useful as well, but if there's no way to filter users or define which fields to display, the use cases seem somewhat limited. In comparison WP-CLI makes it possible to filter users by specific fields (very handy on larger setups), and there are commands for creating users, setting field values, making bulk edits, etc. (Considering the big picture, instead of grouping "users" under "pw" as a single command, it might make more sense to define "users" or "user" as a namespace and "list" as a single command under that namespace.)

Thanks for elaborating! When you put it like that, it definitely seems like a lot ? In my case (using the core approach) the process boils down to this: Translate the word in admin Click the "view" link to display current CSV content Manually copy and paste the new string from the CSV content in admin to existing CSV file bundled with the module git add + commit Manual step is required to copy the data, and another manual step is required to update translations for a module on another site, but to me personally it doesn't feel like a very big deal. Additionally I would never allow PHP to write anything directly into the modules directory — in my opinion it is a very risky thing to do, so that option is out of the question ? Anyway, since the core has a system for bundling translations with modules, it would make sense to see how it could be improved so that perhaps we don't need "competing" solutions. From this thread alone I've picked a couple of ideas that would (in my opinion) make sense as core additions, and I'm planning to open requests or submit PRs for those.