bernhard

7 hours ago, chcs said:

Method Pageimages::focus does not exist or is not callable in this contextProcessWire\Pageimages Object

Your $targetImage is not a Pageimage but a Pageimages object. That's the case when output formatting is off or you request the image via $page->getUnformatted('myimagefield') or similar.

To get the Pageimage (singular) object from a Pageimages object you can do $images->first() or ->last() etc.; see https://processwire.com/api/ref/pageimages/ and as it extends WireArray also https://processwire.com/api/ref/wire-array/

16 hours ago, Kiwi Chris said:

I wonder if in a migration for a module at least, that's using config migrations, whether it would be possible to define a watch list of fields and templates so that any time these are changed via the GUI, their individual migration file will be updated? They probably would still need some manual editing to remove unnecessary properties, but a good diff tool can do this quickly.

If you want to implement this go ahead. I'm not going to do that, because it's a free module and I don't have any benefit in doing so, because I'm faster writing migrations by hand. It's very fast and it's very reliable. Any other steps involved add possible errors and there might be several edge cases to think of. But I guess this would be great for some people, that's why I said I'd love to have it work like this.

From what I thought about it so far I thought it would make sense to have some kind of "check-in" where you click on "watch this field for changes" and then it stores the current config migration somewhere and only writes changed properties to the config migration file. But again - it's nothing that I need for myself.

16 hours ago, Kiwi Chris said:

What happened here is I defined the fields via the UI as normal fields without any prefix, then copied the definitions from the UI into config migration files.

I guess you have some hardcoded ids in your config migrations. That's another problem with these automated exports compared to writing migrations on your own. If you write a migration on your own you can use template/field/etc NAMES instead of ids. That leads to a lot better readable migrations (field => "whatever" vs. field => 123). I guess you have a fieldgroup_id => 123 somewhere and that's the same id of the fieldgroup that your original template uses. In PW in the GUI you only define the template, but internally a template has a fieldgroup that defines the fields that the template uses. And multiple templates can use the same fieldgroup and this is what you are seeing.

16 hours ago, Kiwi Chris said:

Do I still need to follow the convention of site/RockMigrations/templates, site/RockMigrations/fields etc?

Please check out the docs. If you are missing something let me know.

16 hours ago, Kiwi Chris said:

My migrations probably don't need to be part of a module however I started thinking about a website itself like an object. Even the most basic website will probably have certain fields and templates to be functional. Depending on what else it does, it will need additional fields and templates that extend that base. If I decide I want to refine that base, I can do it in one place and apply it to all sites that use it without having to copy and paste any code if I have it defined in a module.

Yeah I have always tried to have some kind of starter profile / module that I can reuse, but in reality most of the time I start over from scratch as it's fast and you don't get any overhead... But as soon as you have a feature that makes sense for more projects just create a module for it and migrations will be your best friend.

You can check out this module: https://processwire.com/modules/breadcrumb-dropdowns/

17 hours ago, Kiwi Chris said:

I love the concept of config migrations with each field and template having its own file

me too 😉 

17 hours ago, Kiwi Chris said:

I want to avoid this, but still like using the ProcessWire UI to design fields and templates, because I'm forgetful and can't remember all the properties and what they do, and I find the UI reminds me, but once I've created or updated a field or template, I want to add it to a migration file so that it's easy to update across multiple sites.

I'd love to have a feature, where you add/setup fields via the GUI and then click a button "save as migration file" with all the changed properties that differ from the default. But unfortunately it's not so easy (because some properties have slightly different syntax or you might get circular references or such things).

And we have snippets, which makes it very easy to create fields. Once they are in place (when using VSCode/Cursor/...) you create a new file with the name of the field/template/etc.. and you type "rmf-text" and you'll get the code for a textfield migration. Then you chance all the settings that you need (or do it via the GUI and copy things over) and that's it. You have to remember maybe 10 properties/words to get 90% of the migrations that you need (columnWidth, label, type, notes, collapsed).

--------

Not sure what is going on in your screenshot. Looks like it's using the fieldgroup of another template. Don't know why that's the case but it's nothing that I see in any of my projects.

Regarding the prefix: Not sure if your migrations need to be part of a module? You can also place them in site/RockMigrations and there a file whatever.php will create a field called "whatever", not "someprefix_whatever". Then you can just copy and paste the templates and fields that you need over to the next project. But as soon as you want to make things more isolated and want to have migrations in a module the prefix makes sense as it will make sure we don't get naming collisions (eg multiple "body" fields or such).

Hope that helps.

As far as I know what you did is still the best solution: https://github.com/processwire/processwire-issues/issues/649

Hey @Pavel Radvan the update is already on the dev branch of RockFrontend

18 hours ago, FireWire said:

If I remember correctly, @bernhard had/has an example PW site that you could log into, make changes, save, delete, whatever, and every X amount of time or PW event all the changes are reverted. If that's true perhaps he can share that and some tips based on his extensive knowledge and experience;

I wouldn't call it extensive knowledge 😅 It was just a regular PW installation that was copied via cronjob to another vhost on the server (both files and DB).

Hey @gebeer thx for that report! I have pushed your suggested fix on the dev branch of RockFrontend 🙂 

It's a great module either way!

Quote

Deprecated: Fluency\FluencyMarkup::ul(): Implicitly marking parameter $id as nullable is deprecated, the explicit nullable type must be used instead in .../site/modules/Fluency/app/FluencyMarkup.php:123

🙂 

@spoetnik does the latest version of the less parser fix all issues and make it work with the latest version of UIkit?

hi @Jonathan Lahijani I can't remember of any flag that I set, but there is $config->external that should be true when used from the cli, which is the case with rockshell.

1 hour ago, Jonathan Lahijani said:

Somewhat related: Does it make sense to have RockShell put ProcessWire in CLI mode by default, because currently it doesn't do that and my assumption is that it would?  Not sure of the pros/cons of doing that, but I'm assuming you given it some thought.

What is "put PW in CLI mode?", I don't understand.

16 hours ago, ryan said:

I'm always interested in making updates to the modules directory, but over time as bandwidth is available to do so.

Thx for the heads up. That's perfectly fine, but it would help if you let us know if something is considered to be implemented in a day, a week or a year or not at all. It would be very frustrating if I went through all my modules and then on the next weekly post get informed that the the requested update is ready and all efforts were useless.

16 hours ago, ryan said:

So currently the modules directory does require a populated README.md in your GitHub repo.

I'm confused. My modules are in private git repos. How would I do that? I also tried to add content to the README.md textarea input in the modules directory but it didn't work because I didn't provide a Github url. But providing a Github url to a private repo makes no sense to me.

16 hours ago, ryan said:

Any module missing a populated readme shows that message.

I understand it is like this, we can see that. My question was does it have to be like this. I don't think it adds value to anybody, especially not to guest users, as I tried to point out.

16 hours ago, ryan said:

For paid modules, that's a category called "premium modules", so if you add your module to that category it should show up as a paid module.

RockCalendar has had this category selected but still doesn't show up. At first I thought the issue might be that I used "premium modules" as second category, but still it does not show up even though I flipped both selected categories. I guess it's because I don't fill the Github url field.

The logs directory definitely does NOT need 775. See https://processwire.com/docs/security/file-permissions/#permission-755-for-directories-and-644-for-files

755 is the least restrictive recommendation and as ryan notes if it can be locked down further its recommended to do so. If it only works for you with 775 that's a good and a bad news:

• good: you know that permissions are the issue
• bad: you should fix it properly to make it work with 755

...which should be the case if the webserver runs as the same user that owns the directory and log files. You might want to talk to your hosting company if you are not hosting it yourself.

On 9/9/2025 at 1:04 PM, biber said:

644

This means that only the owner of the file can write to it. Does it have the correct owner?

@ryan still none of my paid modules show up in the modules directory.

Also do you have some feedback on my questions/suggestions from 4 weeks ago here and here? I'd like to know if you plan to add the suggested improvements or if I have to update all my modules manually.

When I look at the RockPageBuilder module it (still) looks like this:

Is that warning really necessary? Why is that warning shown to regular (non-logged-in) users? IMHO it doesn't add any helpful information for them. How would a guest user add or update the readme of my module?

I understand that my module does not have a readme, but it has extensive docs here: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/

I put a lot of effort into these docs so it is frustrating that all that is visible in the modules directory is an ugly red warning. Even worse I think this warning can make the impression that the module is dead or not actively maintained, which is not the case and which would be harmful to my business.

The "Project" button does nothing when I click on it. What is it intended to do? And why does it appear on my modules page?

And all that said, why does that lead to my modules not being shown in the list of paid modules? Or is there another reason for that?

Next, a minor thing: Why does it show "Since 2025/01/10" and does it have to be like this? On my releases page the oldest release is v3.6.0 from January 2023 and it would be nice to make it obvious that this module has a long history and has always been actively maintained, updated and improved. I understand that this is likely the date when I added the module to the directory, but it's imho nothing that adds value to my module's entry. Could that be made configurable so that I can show the real release date or instead only (not additionally) show the last updated date there, which would be more helpful information for anybody I guess?

Thx

Of course RockMigrations can do that.

Example migrate.php:

<?php

namespace ProcessWire;

$rm = rockmigrations();

// install modules
$rm->installModule('TracyDebugger');
$rm->installModule('RockDevTools');
$rm->installModule('RockFrontend');
$rm->installModule('AdminThemeUikit', [
  'toggleBehavior' => 1, // consistent
  'themeName' => '', // original theme
]);
$rm->installModule('RockAdminTweaks', [
  'enabledTweaks' => [
    'General:QuickAdd',
    'Inputfields:CopyFieldNames',
    'Inputfields:ImageDownload',
    'PageList:TemplateLink',
    'PageEdit:PrevNextPage',
  ],
]);
$rm->installModule('Less', [
  'useCache' => 1,
]);

Glad if it is helpful! I have just pushed an update to the dev branch 🙂 

13 hours ago, DrQuincy said:

In other words, if you are wanting to manage access to assets you cannot use a static 404 HTML file. Is that right? It makes sense but I just wanted to check.

I don't think so but I don't have time to look into it 🙂 

Ryan wrote a blog post for you: https://processwire.com/blog/posts/optimizing-404s-in-processwire/ 😉 

11 hours ago, poljpocket said:

I am trying to get as close to a mergeable implementation as possible.

Would you mind sharing your sources for what makes code mergeable?

Hey @gornycreative that's not planned from my side and I'd not recommend adding it unless you really don't have another option. I added this once so that I can create different colored versions of one website, but using css variables for this is much better! When you use LESS variables you need to keep track of every stylesheet that you generate, eg style-magenta.css and style-blue.css; having 10 colors means having 10 css files to create and load, whereas when using css variables it's just one!

With css variables you can even set different color schemes within one page just by setting a new value for your --theme-color or whatever css variable: <section style='--theme-color: red;'>...</section>

5 hours ago, ryan said:

Does anyone know what this "install processwire" thing is that occasionally appears on my android phone when I go to the website?

The browser does that because you have a manifest file which means it is a PWA that is installable and therefore the browser shows the install prompt (https://processwire.com/site/favicon/site.webmanifest), see here: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Trigger_install_prompt

Got it working, thank you very much! 🙂 

If anybody else if having trouble, here is how to do it:

First, add this to your ddev config:

web_environment:
  - TRACY_LOCALROOTPATH=$DDEV_APPROOT/

This will add the path of the project root as getenv('TRACY_LOCALROOTPATH') in the web container so that you don't have a hardcoded path in your config.

Next add these mappings in init.php:

\Tracy\Debugger::$editorMapping['/var/www/html/public/'] = getenv('TRACY_LOCALROOTPATH') . 'public/';
\Tracy\Debugger::$editorMapping['/var/www/html/src/'] = getenv('TRACY_LOCALROOTPATH') . 'src/';

Interesting! As I didn't know what you mean exactly I asked perplexity:

Quote

Adam Wathan, the creator of Tailwind CSS, has publicly stated his regrets about adding the @apply directive to Tailwind. He has mentioned on Twitter that @apply "basically only exists to trick people who are put off by long lists of classes into trying the framework," and he recommends against using it in most cases. He has also said that @apply is the feature that causes the most issues for the Tailwind team and that they spend the most time debugging it.

The main criticisms from Adam and others around @apply are:

• It goes against the core philosophy of Tailwind, which emphasizes using utility classes directly in your markup rather than abstracting them away in CSS files.
• Overuse of @apply can create maintainability problems and unexpected CSS issues, leading to technical debt.
• Adam has bluntly said he regrets adding it and wishes he could "uninvent" the feature.
• If you’re concerned about using DaisyUI or any other tool that heavily relies on @apply, this context from Adam himself helps explain why some Tailwind community members hesitate to embrace solutions built on that directive.

Hm... doesn't make it easier 😄