bernhard Posted August 1 Author Share Posted August 1 RockMigrations v5.1.0 The automatic detection of the php version/command on the remote when using deployments has been further improved and some issues have been fixed. Breaking Change: We now share the sessions folder by default on deployment. If you don't use RM deployments there is no breaking change and you can simply update. Another fix for deployments: We now use a timestamp like release-20240801220000-12345 because github deploy ids jumped from 999... to 1000... which broke the folder rename operation of deployments. Added automatic modules refresh on $rm->installModule(); Before this change I sometimes had the situation that I had to do a manual modules::refresh on my remote after pushing a new version that installed a new module. This is not the case any more ? You can now (again, as this has been there before but was removed in the last release) define the remote PHP command in your deploy yaml file if the automatic detection should not work for whatever reason. Simply add something like PHP_COMMAND: /path/to/your/php_binary_81 Added getTemplateIds() method that can be handy when PW wants template ids but you want to define that in a human readable way like $foo->bar($rm->getTemplateIds(['home', 'basic-page'])); 1 Link to comment Share on other sites More sharing options...
Sanyaissues Posted August 7 Share Posted August 7 On 7/24/2024 at 2:58 AM, bernhard said: In the module settings you have a checkbox to copy snippets over to /your/project/.vscode and that should make VSCode recognise the snippets and show suggestions once you type "rmf-" etc Thanks @bernhard! rmf- suggestions are working for me. But I cannot find a way to see methods as createPage, deleteField as you do in your video. If you can point me in the right direction I would appreciate it. Spoiler From your video (sorry the quality). My VSCode. Link to comment Share on other sites More sharing options...
bernhard Posted August 7 Author Share Posted August 7 I'm using https://intelephense.com/ and paid for it as it is so useful, but the free version is great as well! 2 Link to comment Share on other sites More sharing options...
Sanyaissues Posted August 7 Share Posted August 7 Seems like after updating the DDEV instance some extensions were removed from the container, after reinstalling intelephense the methods are working. Thanks! Link to comment Share on other sites More sharing options...
bernhard Posted September 2 Author Share Posted September 2 RockMigrations v5.2.0 Added a snippet for the RockIcons module/fields. Added a deprecation note for Magic Field Methods. This feature has been moved to RockFrontend, because the way I implemented it to RockMigrations was not ideal. It added a hook for every existing field, which was something I wanted to change for a long time. But as I didn't see any noticable performance penalties it didn't happen until recently 😎 If you have been using magic field methods be sure to update RockFrontend to the latest version and refactor your code until you don't get any deprecation notices in your logs! Logs will be shown in the "magic-pages" log and will even have a notice how to fix it: 1 Link to comment Share on other sites More sharing options...
FireWire Posted September 7 Share Posted September 7 Having an issue where RockMigrations is running constantly, every 2-5 seconds from the looks of it. The log says "detected changes in migrate.php" but I didn't make any changes. I commented out everything in migrate.php and it continues to happen. It also said that it detected change in two RPB block PHP fields that didn't have any changes, so I deleted thos but no dice. I don't know where to start debugging. I disabled migrations in the module config and RockMigration continues to run and logs "Migrations disabled via module settings'. I've closed every tab but one and Tracy continues to show new log entries for RockMigrations so it appears that migrations are running on every request that ProcessWire handles, even when loading one page. I've upgraded RockMigrations, RockFrontEnd, RockPageBuilder in case there were any conflicts in versions. Any insights? Link to comment Share on other sites More sharing options...
bernhard Posted September 8 Author Share Posted September 8 Are your time settings correct? Maybe filemtime produces a wrong result or maybe time(). Those are compared and if one is wrong it could think the file changed Link to comment Share on other sites More sharing options...
FireWire Posted September 8 Share Posted September 8 @bernhard Found the culprit. RockMigrations is not compatible with WireCache: Filesystem. If both are installed it causes migrations to run on every PHP request that ProcessWire handles and may cause the UI to hang in certain instances. I disabled filesystem cache but given it's speed it would be great if that compatibility could be made. Possible? Found this a bit ago but I forgot to hit the submit reply button 🤷♂️ 1 Link to comment Share on other sites More sharing options...
bernhard Posted September 8 Author Share Posted September 8 @FireWire glad you found the issue. Could you please open a new thread for this and explain the benefits of filesystem cache and how you are using it? Then we can discuss there in an isolated environment which makes it easier to reply, link, refer to... Please also explain your use case as I've never used filesystem cache. Link to comment Share on other sites More sharing options...
bernhard Posted October 1 Author Share Posted October 1 RockMigrations v5.3.0 Added an automatic Modules::refresh() before executing $rm->installModule() Added GET_PHP_COMMAND for deployments as requested by @snck Added docs for the great filesOnDemand feature 1 Link to comment Share on other sites More sharing options...
bernhard Posted October 7 Author Share Posted October 7 We always have to deal with exceptions, right? I'm always using the $rm->setPageNameFromTitle() helper that will update the pagename according to the page title on save. That's easy to do in a MagicPage: public function init(): void { $rm = rockmigrations(); $rm->setPageNameFromTitle($this); } But what if we wanted to make sure that one page has a custom page name that can't be changed, so that we can rely on the url eg in a fetch() call? public function onSaveReady(): void { if ($this->id === 6840) $this->name = 'versandkosten'; else rockmigrations()->setPageNameFromTitle($this); } We have to use the magic "onSaveReady()" method, because in init() and in ready() we cannot use $this to access the current page, because init() and ready() are triggered on a NullPage object and not the page itself. The reason for this is interesting but not for this post 🙂 Link to comment Share on other sites More sharing options...
bernhard Posted November 3 Author Share Posted November 3 RockMigrations v5.5.0 Added PR #65 from lemachinarbo that improves the moduleInstall command; Thank you! 🚀 Added support for config migrations: See docs This update is extremely helpful and from now on the recommended way to write migrations, as this workflow makes circular references a problem of the past! 🥳💪 Added docs about automated releases 2 Link to comment Share on other sites More sharing options...
bernhard Posted 16 hours ago Author Share Posted 16 hours ago RockMigrations v6.0.0 I'm really sorry, but I had to introduce a breaking change if anybody already adopted the new config migrations. It's unlikely, because this addition was only 10 days old, but I bumped to v6.0.0 to be safe. If you have not yet used config migrations you can just update without issues. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now