bernhard

ChatGPT helped me to improve RockMigrations - it's a little scary but it really saved me time today. First, I wanted to support single paths (not json) in the workflow file definition: That worked after I adjusted the variable defaults of input.PATHS to "{}" so that the parsing does not throw an error. No idea why it actually seems to parse the json even if the if-condition is not met, but it works now, so I'm happy with that. Then, as that worked quite well, I tried to fix a warning that I've been getting for quite some time and that worked even better: All updates are on the dev branch.

Hey @Stefanowitsch thx, I've pushed that update to v2.33.0 ? Not sure if it's intentional, but you don't need the class "rf-scrollclass" on your <header>, you only need the attribute. Also I've been thinking if something like this would make sense: rf-scrollclass="show@300-800" ? But I can't think of a scenario where I'd really need that?! The feature was only developed for to-top scrollbuttons that appear when scrolled down for a certain amount. Not sure if it could be helpful for anything else?

Sure, I forgot to mention that I've also added the suggested fix and it works for me on 3.0.214 ?

Great ? It's been some time that I had my head into admin style development, so I'd have to invest time to get into it again. Maybe it just needs better docs to get started and to clearly communicate what module authors need to watch out for so that everything works in every scenario? Where is that variable coming from? Is that already part of uikit or did you add that? Nothing to be sorry about. Didn't want to sound offending, sorry if I did. You might have a look at https://github.com/baumrock/Scss - I developed it for the purpose of quickly creating PRs as the core uses SCSS and not LESS. I'd not really care about what to use, but I think as AdminThemeUikit uses LESS it might be better to stick to less. Also it just works for me and I have no experience when it comes to compiling uikit from scss sources (which exist I think). Not sure if that is anything helpful but I wanted to add that to the brainstorming ?

I've also had issues with that on RockMigrations when testing some yaml features so I'd be happy for a good solution ?

Hey @Richard Jedlička am I missing anything or are you asking for a PR to remove one slash in one file as @szabesz already explained? I think it would be less effort if you just changed that file yourself (you could do that even in the browser) than having someone make a pr and approve and merge that ?

Hey @flydev it's a nice theme, just tried it again as I'm getting more used to dark mode in general. I'm not sure about how we should approach this. I think before we ask module developers to adopt to our workflow we'd need to find a solid workflow for ourselves and find standards that we can agree on. For example it seems that your style does not use my rock-primary convention? Also why are you suggesting SCSS when the module and AdminThemeUikit use LESS for everything? Here's a project with your style: And here it is with my style: What I find great about the rock style is that I can simply set a primary color in the module's settings and the backend instantly fits to the clients CI: Your module has this yellowish primary color which in my case should be #00bb86 ? Another thing is that my PageBuilder uses SVGs for showing available content elements: I'd not be extremely happy if I had to add support for dark themes here. But that's obviously only a topic of lazyness efficiency ? I'm happy that you try to move forward here and I agree that module authors should provide the stylesheets for supporting dark styles. But I also think we should make it as easy as possible so that it's as little effort as possible.

Hey @flydev great to hear that ? Unfortunately there is an issue with my approach of reading the version number from the json. It will break the version number in the PW modules directory (as you mentioned). I've asked Ryan to make the modules directory grab the version from package.json if it does not find a version in the info file/method. Hopefully he will add that. The workflow is a huge time and brain saver for me every day. See https://github.com/processwire/processwire-issues/issues/1690 I'm also using this approach now not only for my modules but also for the project's main repository. It's great. I push to dev and github deploys the site to staging. I push to main and github creates a new release and then pushes that release to production ?

v3.19.0 comes with a new magic method to easily set the page name whenever a page is saved: public function setPageName() { if (!$this->year()) return uniqid(); return $this->title . "-" . $this->year(); } It will also lock the page name field and show a hint so that everybody understands what's going on:

Thx @Stefanowitsch fixed in v2.31.2 ?

@Stefanowitsch thx for the report. Could you please provide a step by step instruction what you did so that I can try to reproduce the issue?

Hi @maetmar thx for spotting! Please check v2.31.1 ?

Hey Adrian I get this error on the latest version. Thx in advance ? ErrorException: Undefined variable $toMethodName in /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/DebugModePanel.php:216Stack trace:#0 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/DebugModePanel.php(216): Tracy\Bar->Tracy\{closure}(2, 'Undefined varia...', '/var/www/html/s...', 216)#1 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(145): DebugModePanel->getPanel()#2 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(117): Tracy\Bar->renderPanels('')#3 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(91): Tracy\Bar->renderPartial('main')#4 /var/www/html/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Debugger/DevelopmentStrategy.php(139): Tracy\Bar->render(Object(Tracy\DeferredContent))#5 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Debugger/Debugger.php(321): Tracy\DevelopmentStrategy->renderBar()#6 [internal function]: Tracy\Debugger::shutdownHandler()#7 {main}

Thx for the feedback @wbmnfktr I'm a little confused - are we talking about RockMigrations or RockFrontend? Or both? I know that the docs can be improved in most of the modules. The problem is that it's really not an easy task for me. Any help like this great post by @Stefanowitsch is very welcome. The problem that I have with the github readme is that it get's too long for modules like RF and RM. That's why I started using github wikis - but I'm not really happy with them. They are not part of the version controlled files and so they are not connected with specific releases of the module. But I already have a plan to improve that ? Maybe you can share your experience a little more detailed? What is your goal? Why do the modules look interesting? What parts do you want to use? How did you try that? Where exactly did you fail?

FYI RockMigrations has a nice helper for using xdebug on ddev:

Yeah just my RockMigrations checkbox is only for VSCode. But if you tell me what is necessary for PHPStorm I can maybe add that as well?

Very interesting: Mapping Heritage: Geospatial Online Databases of Historic Roads. The Case of the N-340 Roadway Corridor on the Spanish Mediterranean https://www.mdpi.com/2220-9964/7/4/134/htm

Thx again for the great post! Just realised that you are using old-school paths, this would also work (I call it smart paths): <?php $rockfrontend->styles() ->add('styles/less/uikit/_custom-import.less') // add single LESS or CSS file ->addAll('styles/less/project') // point to folder to include files automatically ->addAll('styles/less/custom') // or this would also work (even if pw lives in a sub-folder!) $rockfrontend->styles() ->add('/site/templates/styles/less/uikit/_custom-import.less') // add single LESS or CSS file ->addAll('/site/templates/styles/less/project') // point to folder to include files automatically ->addAll('/site/templates/styles/less/custom')

v3.16.0 adds an xDebug launch.json file to the .vscode folder and a checkbox to control whether you want to use that feature or not. That means if you are using DDEV all you need to do to is to check the checkbox and then run "ddev xdebug on" Thx @dotnetic for the hint about xDebug on DDEV! I've just tried it today and it works great! compared to my last experience with xdebug on laragon where performance was really bad the performance on my ddev container is so good that I even forgot to turn it off today ? Page load times without xdebug: 100ms; with xdebug: 150ms ? And all that with zero-config!!! You have to try it ? See here how to use xdebug in vscode: https://www.youtube.com/watch?v=HrQWtbxY1Hs&t=331s

I haven't read everything carefully and I have never used the feature myself, but TracyDebugger has a feature to render different template files with a customizable suffix. Here is how adrian implemented it: https://github.com/adrianbj/TracyDebugger/blob/f2fbcd88fcecad45b2ce7b428cfe80c1527c1122/TracyDebugger.module.php#L1481-L1494

I've created a new thread for that topic:

I'm creating a new topic in response to @cst989's question in the RM thread as I think this is a common question and misunderstanding when evaluating RockMigrations. It's also easier to communicate in separate threads than in one huge multi-page-thread... Hi @cst989 thx for your question and interest in RockMigrations. This sounds like you have a misconception in your head which is quite common I guess. Did you watch my latest video on RM, especially this part? https://www.youtube.com/watch?v=o6O859d3cFA&t=576s So why do you think it is a good thing to have one file per migration? I know that this is the way migrations usually work. But I don't think that this is the best way to do it. I'm not saying one way is right and the other is not. I'm just saying I'm having a really, really good time with RockMigrations and it makes working with PW in a more professional setup (meaning either working in a team and/or deploying PW to multiple locations and of course managing everything with GIT) a lot more fun an a lot faster and more efficient. If we look at how migrations usually work we can have a look at the other PW migrations module, which works just like usual migration modules work: You create one file per migration and you end up with a list of migrations that get executed one after another. See this screenshot from the modue's docs: In my opinion that screenshot perfectly shows one huge disadvantage of that approach: You don't see what's going on. You end up with a huge list of migrations that you can't understand on first sight. In RockMigrations this is totally different. You don't create one file per migration. You put all the necessary migrations where they belong and - in my opinion - make the most sense. An example: Let's say we want to add 2 fields to the homepage: "foo" and "bar". Ideally you are already using Custom Page Classes (see my video here https://www.youtube.com/watch?v=D651-w95M0A). They are not only a good idea for organizing your hooks but also your migrations! Just like adding all your HomePage-related hooks into the HomePage pageclass init() or ready() method, you'd add the migrations for your 3 fields into the HomePage pageclasses migrate() method. This could look something like this: Now let's say we develop things further and realise we also need a "bar" field: Do so see what we changed? I guess yes ? Now one big difference to a regular migration approach is that you don't write downgrade() or reversion migrations - unless you don't want to revert the changes! In real life I've almost never ever needed to revert changes. Why? Because you develop things locally and only push changes you really want to have on your production system. If you happen to have to remove some changes that you applied on your dev it's easy to do, though: You see what we did? Nice! So does everybody else that has access to the project's GIT repo! So all your team mates will instantly see and understand what you did. Pro-tip: You don't even need lies 43-45 if you didn't push those changes to production! If you only created those fields on your local dev you can simply restore the staging database on your local dev environment and remove the migrations that create the fields. Pro-tip 2: Also have a look at RockShell, then restoring staging or production data is as easy as "php rockshell db-pull staging" Pro-tip 3: When restoring a DB dump from the staging system it can easily happen that you have data in your database that was created only on the remote and you don't have on your dev system (like new blog posts for example). If you then open those new blog posts on your dev system processwire and the blog post contains images processwire will not be able to show those images (as only the file path is stored in the DB and not the whole image!). Just add $config->filesOnDemand = "http://yourstagingsite.example.com" to your config.php file and RockMigrations will download those files once PW requests the file (either on the frontend or also on the backend)! Having all your changes now in your git history you can even jump back and forth in time with your IDE: You could. I thought about that as well. But I think it does not really make sense and I hope my examples above show why. I'm always open to input though and happy to try to think about it from other perspectives. One final note: I'm not sure if what you say about $rm->watch() makes sense here. If you watch() a file that means that RM checks it's modified timestamp. If that timestamp is later than the last migration that RM ran, then RM will automatically execute the migrations that are in that file. All other files and migrations will be ignored. That makes it a lot more efficient when working on projects that have many migration files in many different places. When triggered from the CLI though or if you do a modules refresh then it will always trigger all migrations in all watched files. I hope that makes sense! --- Ok, now really a final note ? One HUGE benefit of how RockMigrations works (meaning that you write migrations in page classes or in modules) is that you create reusable pieces of work/code. For example let's say you work on a website that needs a blog. So you create a blog module and in that module you have some migrations like this: <?php $rm->createTemplate('blogparent'); $rm->createTemplate('blogitem'); $rm->setParentChild('blogparent', 'blogitem'); $rm->migrate([ 'fields' => [...], // create fields headline, date, body 'templates' => [...], // add those fields to the blogitem template ]); You'd typically have those lines in Blog.module.php::migrate() What if you need a blog in another project? Yep --> just git clone that module into the new project and execute migrations! For example in migrate.php this: <?php $rm->installModule('Blog'); If you follow a regular migrations concept where all project-migrations are stored in a central folder you can't do that! Of course you don't have to work like this. You can still write all your migrations in the project's migrate.php file. Because I have to admit that it is a lot harder to build a blog module that can be reused across different projects than just creating one for one single project! It always depends on the situation. But - and now I'll really leave it for today ? - you could also make your Blog-Module's migrate() method hookable and that would make it possible that you build a generic blog for all projects and then you add field "foo" to your blog in project-a and you add field "bar" to your blog of project-b. Have fun discovering RockMigrations. I understand it can look frightening at first, but it is an extremely rewarding investment! Ask @dotnetic if you don't believe me ?

Ah, that's a different question then ? You can look into TracyDebugger's module disabler feature then. There might be some helpful snippets?

You can provide a selector or a callback as "autoload" property of your module config: https://processwire.com/talk/topic/3768-processwire-dev-branch/#comment-36787

The most important question would be how you save dates in the DB. How do you handle endless recurring dates? Do you set a hard limit on numer of recurrences? Or do you set a limit on the year in the future? etc etc.