bernhard

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. 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. Please check out the docs. If you are missing something let me know. 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/

me too 😉 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

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!

🙂

@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. What is "put PW in CLI mode?", I don't understand.

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

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