bernhard

Just had a look at the code and some cleanup would be nice for sure (though not necessary imho). How would that work? For example the method "addFieldToTemplate(...)". How would I move that method to another file without changing the api? I know it would be possible to add that method to $rockmigrations via API addHookMethod, but that makes it a lot more complicated to develop and to also support proper intellisense. Also I guess it would have more overhead.

Ah, I always read ProfileUtilities instead of ProfieldsUtilities 😄 Well anybody could just develop his/her own module based on RM Just create an autoload module that requires RockMigrations, then in the init() method one could do this: public function init() { $this->wire->rockmigrations->fooPlugin = $this; } And then anybody could use that plugin like this: $rockmigrations->fooPlugin->doSomething(); But I'm not sure how useful that would be compared to calling the module directly: $foo = $modules->get('fooPlugin'); $foo->doSomthing(); I know that feature, but I just don't know what benefits you are thinking of..

Hi Ivan, I really appreciate your input and I'm very happy to see your interest in RM growing. Though I have some concerns about your suggestion. Not saying that are bad suggestions, I just try to be realistic. First of all: I'm really, really happy with RM and how it works right now. There has been a lot of refactoring from RM1 to RM2 and that has brought a lot of improvements to the module. The API is in my opinion quite easy and stable to use and the concepts have proven to be working. Second: It's a free module. I think it's one of the best and most powerful modules out there for PW and it can bring a HUGE value to your everyday work, especially if you work in a team or want or need more professional workflows with zero-downtime deployments on multiple environments etc.; I decided to release it for free, because I think this should be part of the core. It should be something that every developer can use to create great modules. To use it as a foundation for, eg quickly and easily create a blog module that creates all the necessary fields and templates that you get a one-click blog setup for ProcessWire. That's simply not possible to do with site profiles and it's simply a pain to do with the regular API. Unfortunately that did not happen. Quite the contrary. People complained about it being too complicated (and didn't even use the module once). And no one ever used RM to create something useful for the community as far as I know. I'm not complaining - it is like it is, but that's the context for the question you are asking. That said, back to topic: I've been talking with @gebeer about refactoring quite some time ago: --bernhard-- In the long term, however, I thought it might make sense to split the API. Similar to how the wire core is split into its own classes. $rockmigration->fields->create('foofield'); $rockmigration->templates->addField('foofield', 'bartemplate', afterfield: 'title'); $rockmigration->migrate([ ... ]); That would really be a completely different API... That means a mega breaking change. I don't know if it's worth it...... --gebeer-- In the long run it's not wrong because it brings more structure into the API. But I think the API is well usable as it is. But I'm still not sure if it would be better. I really like the simple API that is accessible via $rm: Also splitting the API brings in other problems. Many methods do something with two things, eg "addFieldToTemplate" - would that be $rm->fields->addToTemplate("myfield", "mytemplate") or would that be $rm->templates->addField("mytemplate", "myfield") ? I don't understand 🙂 If you have specific ideas I'd be more than happy to hear them and think about how we can improve the module and/or the code quality.

Yes 😎 The module is done and ready for production. Just the infrastructure to sell it is not, as we unfortunately have no dedicated place to sell commercial 3rd party modules in the PW ecosystem 😞 If you are interested just send me a PM and you'll get a horrible and outdated preview video 😄

Your error message tells something different 😉 That means that the module tries to write to css/style.css which is obviously not a correct file path. This means that your IDE complains about the syntax, which could mean that your IDE uses a different PHP version than your project. If your IDE uses something like PHP7.4 then it will check your code with that interpreter and complain about PHP8 syntax. That does not mean that the code will not run though. But obviously it's something that's not ideal.

you didn't provide the full path as I showed you in the comment above

Should be this: $scss->compileIfChanged( input: $config->paths->templates . "scss/style.scss", watch: $watchFiles, output: '/path/to/css/style.css', // use path and add comma at the end style: 'compressed', // optional but recommended comma at the end );

You need PHP version 8+ I've updated the module with that requirement.

I didn't test includes or imports. As I've never worked with SCSS and LESS has always just worked for me I'd need input from others to make it work. I don't see a reason why RockFrontend should not also support SCSS. It would need some more work though than what I quickly did for this module on Tuesday, so it's not really a top priority 🙂

Hi @jeremie I'm always happy to help. If you don't know me you can get an idea at processwire.rocks and you can schedule a meeting at https://cal.com/baumrock/meet and then we'll do a 1:1 video meeting with screenshare in english or german 🙂

Hey Robin, thx for the tutorial! I just wanted to mention here, if anybody is reading this and looking for a solution, that RockMigrations has both features on board, as that is a very common need when working with PW from code. Page IDs can not be copied like in your example, but they can be shown in the page tree. Maybe I should change that. I like your solution. But on the other hand sometimes it's nice to just see the ID and with your solution you'd have to paste it somewhere just to see the id. On the other hand my solution pollutes the page tree. Maybe a combination would be ideal - a page tree that shows IDs on shift or alt or something and copies the ID on click. This is the very simple tweak that adds page ids to the page tree in RockMigrations: https://github.com/baumrock/RockMigrations/blob/main/tweaks/PageListShowIds.php Regarding the field names - in RockMigrations I had the problem that I not only needed the field's name but also it's possible values. Sometimes that's not as easy as just a 0/1. Sometimes there are string values or sometimes it is -1. I came up with adding a tooltip that shows the field name on hover plus the value of the hovered input element:

Don't forget that, when working with RockMigrations, you can still solve problems without RockMigrations 😉 So you have all the PW magic available, that means you could for example just use $files->copy() to copy files, or you could use exec("cp -r /foo /bar"); That all depends on your system and situation. RockMigrations just helps with an easy API for all the things that usually have to be done manually in the PW backend.

Hi Ivan, the installModule() method just takes the name of the module to install and that's it. At least as long as PW can find that module on the file system. But RM can also download modules for you if you provide an URL (eg the github zip link). Did you read the usage notes of installModule? Or did you experience any other issues? * Install module * * If an URL is provided the module will be downloaded before installation. * You can provide module settings as 2nd parameter. * Usage: * $rm->installModule("YourModule"); * * Install from url: * $rm->installModule( * "TracyDebugger", * "https://github.com/adrianbj/TracyDebugger/archive/refs/heads/master.zip" * ); * * Install with settings: * $rm->installModule("YourModule", ['setting1'=>'foo', 'setting2'=>'bar']); * * Install with settings from url: * $rm->installModule("MyModule", ['setting'=>'foo'], "https://..."); In my projects I usually download modules via the GUI, then I commit those files into the git project. Then I add this to Site.module.php: $rm->installModule('WhateverModuleYouDownloaded'); That means as soon as you push those changes you have all the files you need on your staging/production system and once the migration of Site.module.php is run the module will be installed without any further manual steps.

There are many possible solutions for making urls shorter. In your case you could for example just name the "resources" page "r" then you'd get urls like example.com/r/blog/your-blogpost This thread should be an interesting read for you: Another solution could be a module for creating decoupled menus, like https://processwire.com/modules/process-menu-builder/ . There might be more such modules, though I have to say I have never used one of them and also keep in mind what Ryan has to say about it in the linked thread:

You have to give more context to get proper answers I guess. If "Resources" is not a page, where do pages like /resources/blog etc. really live? Where are they stored? If they are stored somewhere else, why do you want to show them in the menu under "resources"? If you want to show them under "resources", why don't you just create a page "resources" and store them as child? So maybe you are overcomplicating things. But I guess nobody can tell as long as you are oversimplifying your answer 🙂😉

It's this setting on the "input" tab of your page reference field:

Yeah that's why I'm asking 😉 I'm always using LESS and I've built all the tools to easily compile LESS to CSS on the fly. That's not the case for SCSS. I've just pushed an update and updated the readme to support what you need: https://github.com/baumrock/Scss

Just want to mention that ProcessWire has had great frontend editing capabilities for years: And for more complex content (like images) having a modal is not too bad in my opinion: But yeah, I agree that the frontend editing tools could get some love and could be improved. For example the modal could have more events to listen to. And maybe instead of reloading the whole page it would be nice to just replace the corresponding block instead of refreshing the whole page. On the other hand I'm not sure how much benefit that would really bring. A page reload is often helpful or even required (eg for loading different styles or scripts when something changed) and in my opinion it does not really hurt. Compare this to what you linked to: https://aaronmbushnell.com/images/live-reload.mp4 What you see here is a problem that is quite underestimated in my opinion. The barrier between frontend and backend might be easy to grasp for us developers that built the website, but it's not so easy for clients. Which field ends up where in the final design? How does the field "headline" look? It's just text in the backend! You have no visual idea of the final result. And having all fields in a sidebar does not solve these problems in my opinion. I can't even see the changes that he makes for the "accordion"! I see him changing field values, but I don't see where that content is changed on the site... With frontend editing you don't have these problems. Clients can just doubleclick on the text that they see and start typing 🙂 Pssst: RockPageBuilder in action here 🙂 Sign up for https://www.baumrock.com/rock-monthly/ if you want to get notified when I release it or write me a PM.

Do you really want scss or would less also be OK?

Sorry, that was too short 😄 Nope --> That was the answer to your question if your shortcuts make a difference. Just tried to paste it into the html field of jsfiddle.net and it pastes just the text without any markup --> that was something that I tried on my own after your suggestion to see what is actually stored in my clipboard. But that was nonsense, I think. I thought that jsfiddle might also show all the markup with all the tags when pasting, but it just shows text only. I'm not sure why this happens and what's going on and what is actually stored in the clipboard when copying text from websites, but I think a plain text field should be frontend editable without having to worry about encoded markup ending up in the field 🙂

There's now a new tweak in RockMigrations to set all languages of newly created pages active by default:

Nope. Just tried to paste it into the html field of jsfiddle.net and it pastes just the text without any markup 🤷‍♂️ I've created an issue: https://github.com/processwire/processwire-issues/issues/1818

Yeah, feel free to grab it here and improve/maintain it for the future 🙂 https://github.com/baumrock/rockhitcounter

When using DDEV you can check if everything works with your specific installation just by changing a value in .ddev/config.yaml of your project. Here are all the possible database types that are supported: https://ddev.readthedocs.io/en/latest/users/extend/database-types/ Yes, you need to install DDEV first. But you'll never ever have these kind of problems or fears any more. Locally I'm on MariaDB 10.6.12 InnoDB on most projects and have no issues.

I'm using frontend editing all the time. Suddenly on my new project when I tried to copy and paste several regular text-field contents: I ended up with markup in my fields: So I always need to hit the edit icon to edit it in the modal which shows the backend inputfield and there I can safely copy&paste like this: Any ideas why this would happen? I'm not sure why I didn't experience this behaviour so far. Maybe it's an update of something?