RockSettings - Manage common site settings like a boss.

[bernhard]

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!

[zoeck]

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)

[bernhard]

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

[FireWire]

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!

[bernhard]

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?

[FireWire]

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

[bernhard]

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?

[FireWire]

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

 

[bernhard]

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.

[FireWire]

@bernhard Thanks and I'll give that a shot!

[FireWire]

@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

[bernhard]

Hey @FireWire sorry for the trouble. Could you please provide step by step instructions to reproduce this?

[FireWire]

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

[bernhard]

@FireWire cleaning up my inbox ? Did you find anything?

[FireWire]

@bernhardUnfortunately not yet, I have been jumping around on projects and haven't come back to it haha.

[nurkka]

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:

 

[FireWire]

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.

[bernhard]

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?

[FireWire]

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.

[bernhard]

Hey @FireWire I've added the following to RockSettings v2.2.3

  public function ___uninstall(): void
  {
    rockmigrations()->deleteFields("tags=RockSettings");
    rockmigrations()->deleteTemplates("tags=RockSettings");
  }