bernhard Posted January 7 Share Posted January 7 I'm proud to share another module with you. Compared to other settings-modules this module has the benefit that it creates a real page, which means: You can access it via $settings or settings() from everywhere You can upload assets like a logo or global images or files You can add/hide/change all the fields of the settings page as you like It (optionally) adds a settings-icon to the main navbar of the backend It has a redirects feature to create short-links like yourdomain.com/example Download + Docs: https://www.baumrock.com/processwire/module/rocksettings/ If you have feedback or any suggestions for improvements let me know! 5 Link to comment Share on other sites More sharing options...
zoeck Posted January 9 Share Posted January 9 A very nice module, thank you Bernhard! That was a missing function of the Processwire Core ? (even if you could do it via a page) 1 Link to comment Share on other sites More sharing options...
bernhard Posted January 9 Author Share Posted January 9 On 1/9/2024 at 1:15 PM, zoeck said: A very nice module, thank you Bernhard! That was a missing function of the Processwire Core ? (even if you could do it via a page) Thx @zoeck I agree. I talked to Ryan before developing this module, but it seems he didn't see the need for such a feature. I was asking for a dedicated settings page without any fields that we could have as a standard for other modules to build on. Similar to the admin page with id=2 I thought of /settings having id=100 or something. But I'm happy now with this solution and it's already installed on several sites. ? 1 Link to comment Share on other sites More sharing options...
FireWire Posted July 13 Share Posted July 13 Hey @bernhard Everything is working great, just having an issue with fields having their Visibility re-set to 'Open' after refreshing modules. The only affected fields are Logo, Favicon, og:image, Images, and Files. So only the fields under the 'Media' fieldset. All of the other fields keep the visibility as configured in the template settings. Using version 2.0.1 Thanks! Link to comment Share on other sites More sharing options...
bernhard Posted July 13 Author Share Posted July 13 Hey @FireWire fields created by the module are migrated on every modules::refresh, so if fields define a default collapsed state then this will be applied to the field on every migration. This is intended. If you want to override this you can set different settings in template context, then your modifications should keep intact. Or am I misunderstanding? Link to comment Share on other sites More sharing options...
FireWire Posted July 13 Share Posted July 13 @bernhard I am hiding some fields using the template context settings, but only the fields I mentioned aren't keeping those settings. All of the other fields keep the visibility settings. 1 Link to comment Share on other sites More sharing options...
bernhard Posted July 13 Author Share Posted July 13 Hey @FireWire I can't reproduce. I tried the following: Do a modules refresh to make sure everything is set to default Check the logo field - it was opened by default. Edit template "rocksettings" Edit field "rocksettings_logo" in context of this template, set visibility to "closed + ajax loaded" Do a modules refresh again to run all migrations. The field was still ajax-loaded after the migrations. Can you please provide more details or step by step instructions? Link to comment Share on other sites More sharing options...
FireWire Posted July 13 Share Posted July 13 @bernhard It's the strangest thing... I am trying to set it to 'Hidden'. Which works when editing in template context. But after a modules refresh, it comes back with the original visibility. That's the only steps I can come up with ? All of the fields under that 'Media' fieldset keep popping back up after a modules refresh. Link to comment Share on other sites More sharing options...
bernhard Posted July 13 Author Share Posted July 13 Sorry, but I still can't reproduce it even with "hidden" setting... No logo field there... If you want to find the reason I think you have to debug that further and maybe check everything on a fresh install and see when/if you see the same bug. If you want a quick&dirty solution we could try to add a hookable method that runs after each migration of the settingspage where you should be able to override any settings. 1 Link to comment Share on other sites More sharing options...
FireWire Posted July 13 Share Posted July 13 @bernhard Thanks and I'll give that a shot! 1 Link to comment Share on other sites More sharing options...
FireWire Posted July 13 Share Posted July 13 @bernhard Well, I hate to be that guy today (haha) but one more issue and I think it's related to custom page classes(?) Seems odd because DefaultPage extends Page. ProcessWire version 3.0.229 and RockSettings version 2.2.1 Link to comment Share on other sites More sharing options...
bernhard Posted July 14 Author Share Posted July 14 Hey @FireWire sorry for the trouble. Could you please provide step by step instructions to reproduce this? 1 Link to comment Share on other sites More sharing options...
FireWire Posted July 14 Share Posted July 14 @bernhard Wish I had more information but the only step was installing the module. I did some digging but am still coming up short. I removed the custom page classes and still got the error, so we can rule that out. Here's more detailed output after attempting to install again: The site is set up with language support, so that missing method error should not exist. I'm struggling to locate where exactly this issue is coming from because $page->localPath() is working everywhere else. Maybe this is an issue with language support installed before RockSettings is installed? I noticed this on lines 398-400 in SettingsPage.php <?php // make redirects be single-language $tpl = $rm->getRepeaterTemplate(self::field_redirects); $rm->setTemplateData($tpl, ['noLang' => true]); Shot in the dark, having trouble narrowing down where to look to find more information. Link to comment Share on other sites More sharing options...
bernhard Posted August 19 Author Share Posted August 19 @FireWire cleaning up my inbox ? Did you find anything? Link to comment Share on other sites More sharing options...
FireWire Posted August 19 Share Posted August 19 @bernhardUnfortunately not yet, I have been jumping around on projects and haven't come back to it haha. 1 Link to comment Share on other sites More sharing options...
nurkka Posted September 29 Share Posted September 29 I had similar issed with localPath. After some testing I found out that localPath seems to be not a "real" method of Page, but is registered via a hook. Is it possible that the issue "Page::localPath does not exist or is not callable in this context" is a side effect of that? # /wire/modules/LanguageSupport/LanguageSupportPageNames.module public function ready() { $this->addHook('Page::localPath', $this, 'hookPageLocalPath'); } /** * Add a Page::localPath function with optional $language as argument * * event param Language|string|int Optional language * event return string Localized language path * * @param HookEvent $event * */ public function hookPageLocalPath(HookEvent $event) { /** @var Page $page */ $page = $event->object; $language = $this->getLanguage($event->arguments(0)); $event->return = $this->getPagePath($page, $language); } In my case I could simply replace localPath with path, because localPath returns the page path of the default language and not the page path of the current language. This seems to be an inaccuracy in the docs. See this post: 1 Link to comment Share on other sites More sharing options...
FireWire Posted November 9 Share Posted November 9 Should the module "clean up" after uninstall? I am working through some troubleshooting in my module dev environment and part of that is uninstalling all modules to troubleshoot "clean". I uninstalled RockSettings as part of that process and noticed that uninstalling the module doesn't remove the fields it creates. Link to comment Share on other sites More sharing options...
bernhard Posted November 9 Author Share Posted November 9 Hi @FireWire could be that I forgot to take care of that. I've never had to uninstall RockSettings 😄 But all fields should be tagged by RockSettings, so deleting them should be one line with RockMigrations. Then also delete the template and that should be it? 1 Link to comment Share on other sites More sharing options...
FireWire Posted November 10 Share Posted November 10 18 hours ago, bernhard said: I've never had to uninstall RockSettings First time for me as well haha. First time I've ever gone through and uninstalled modules to troubleshoot, turns out it wasn't necessary at all. So that's good news for the quality of everyone's work 😎 I assume RockMigrations would handle it? I guess the order of operations in my work kept that from happening. Link to comment Share on other sites More sharing options...
bernhard Posted Monday at 08:47 PM Author Share Posted Monday at 08:47 PM Hey @FireWire I've added the following to RockSettings v2.2.3 public function ___uninstall(): void { rockmigrations()->deleteFields("tags=RockSettings"); rockmigrations()->deleteTemplates("tags=RockSettings"); } 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