Jump to content

RockSettings - Manage common site settings like a boss.


bernhard
 Share

Recommended Posts

I'm proud to share another module with you.

mPI1pBd.png

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!

  • Like 5
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

  • 6 months later...

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

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

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

@bernhard It's the strangest thing...

I am trying to set it to 'Hidden'.

1648287305_Screenshotfrom2024-07-1311-34-35.png.38f94abad11a8f67194b036398534da4.png

Which works when editing in template context.

221426903_Screenshotfrom2024-07-1311-34-56.thumb.png.17e6dc90c1bd3144dc0eecbc23115327.png

But after a modules refresh, it comes back with the original visibility.

531357642_Screenshotfrom2024-07-1311-38-13.thumb.png.d72a0c885b48e5327158557b1f8c4877.png

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

Sorry, but I still can't reproduce it even with "hidden" setting...

k4JbpG8.png

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.

  • Like 1
Link to comment
Share on other sites

@bernhard Well, I hate to be that guy today (haha) but one more issue and I think it's related to custom page classes(?)

1886476912_Screenshotfrom2024-07-1315-54-13.thumb.png.1f6ee1bdf0fa00b8914713a072047dd7.png

Seems odd because DefaultPage extends Page.

ProcessWire version 3.0.229 and RockSettings version 2.2.1

Link to comment
Share on other sites

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

142853038_Screenshotfrom2024-07-1407-48-55.thumb.png.720c07fccadce1622d48f39390c9751e.png

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.

1273776024_Screenshotfrom2024-07-1410-19-18.thumb.png.c8ac80c45e0853d56a8399fa5c68f173.png

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

  • 1 month later...
  • 1 month later...

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:

 

  • Like 1
Link to comment
Share on other sites

  • bernhard changed the title to RockSettings - Manage common site settings like a boss.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...