superuser is missing rights

[torf]

I've got a strange behaviour on one site I cannot explain. It looks like my superuser is missing some rights and I cannot find out where i could have compromised the system.

- I cannot add any page directly under my root page

- if I click on admin pages i get a strange warning

(Page 3 is supposedly Admin/Pages) After that I cannot open the page lister. It stays empty and giving me an error with the same text. If I log out sometimes it helps, sometimes it stays that way for some time.

- All of my users (including superuser) are missing the "view"button in page lister

I tried to add a new superuser, but that makes no difference. Also I've got the same site in my development server where I have no odd behaviour. Has anybody experienced something like that before? (The Site has been moved via Duplicator - maybe that has changed something?)

[flydev]

Hello,

If the website is working well on dev server, we can assume the site hasn't been compromised and then it seem something is missing from the restore process.

I can take a look right now. Which version of Duplicator did you used to migrate the site please ?

(FYI, I migrated with success two website with the dev version of Duplicator and one confirmed with v1.4.26)

Edited May 11, 2023 by flydev
precision

[torf]

Thanks a lot - I used Version v1.4.21
But the sites are not 100% the same. There is the possibility that something has been changed on production server, or that some read/write access may be different.

[flydev]

Ok. Can you give more details on the prod server ? (database type, charset, version)

I you feel confident, you can send me an access using private messaging. 

[torf]

Database is libmysql - mysqlnd 7.4.33, Server Version: 10.6.11-MariaDB, Server runs on cp1252 West European, DB is utf8mb4_unicode_ci

Unfortunately there is no direct phpmyAdmin access without sending my clients admin access to the whole Domain/hosting.

[flydev]

Ok

55 minutes ago, torf said:

mysqlnd 7.4.33, Server Version: 10.6.11-MariaDB, Server runs on cp1252 West European, DB is utf8mb4_unicode_ci

Database is set to MyISAM or InnoDB ?

 

ℹ️ What I suggest you to do, is :

Short process:

1. make a backup before doing everything
2. empty the database, make sure encoding, schema is the same as the dev server
3. restore your site using Duplicator's installer v1.4.29

Long process:

1. make a backup before doing everything
2. comparing the config.php file and making sure there is no glitch
3. compare the database between dev and prod
4. check read/write permission on the server with ssh

 

 

[torf]

Thanks for the reply. Both are MyIASM, but what I found is that dev is utf8 while production utf8mb3. No idea if that makes any difference.

Doing another export is no option as the production site has hundreds of articles (it's up and running already), but I'll go through it manually.

[flydev]

I think it should work as the difference reside on utf8mb3 use a maximum of 3 bytes and utf8mb4, 4 bytes which is not really important on your issue (supposing it only..)

I will test an utf8 export and restoring it on a mb3 db in less than a hour with Duplicator v1.4.26. Will report result here.

2 hours ago, torf said:

but I'll go through it manually

Yes ok, you should just have to compare the `pages` table with your dev one to spot something. If you find something, please, keep us updated ?

 

PS:  @torf which version of ProcessWire we are working on ?

[torf]

So far I found no strange differences. But that will take some time as the pages are quite different regarding their content.

ProcessWire Version is 3.0.184

What I found in my exeptions Protocol is:

Template changes are disallowed on page 3 because it has system status
In /wire/core/Page.php line 2000

And thats the setTemplate function

protected function setTemplate($tpl) {
		if(!is_object($tpl)) $tpl = $this->wire()->templates->get($tpl); 
		if(!$tpl instanceof Template) throw new WireException("Invalid value sent to Page::setTemplate"); 
		if($this->template && $this->template->id != $tpl->id && $this->isLoaded) {
			if($this->settings['status'] & Page::statusSystem) {
				throw new WireException("Template changes are disallowed on page $this->id because it has system status");
			}
			if(is_null($this->templatePrevious)) $this->templatePrevious = $this->template; 
			$this->trackChange('template', $this->template, $tpl); 
		}
		if($tpl->sortfield) $this->settings['sortfield'] = $tpl->sortfield; 
		$this->template = $tpl; 
		return $this;
	}

But I've absolutely no idea why Processwire would try to set a template when opening the admin branch of the site tree.

[dragan]

Check if you have the same "advanced" settings in both sites:

$config->advanced = true;

Can you open page id 3 (that's Admin > Pages) directly? https://mysite.com/admin/page/edit/?id=3

What do you see in the settings tab? It should look like this, if you have advanced mode activated:

Normally, you shouldn't have to play around with these settings on a default admin (system) page.

Also... seems obvious to check first, but perhaps you have some hooks or your own custom module installed that interferes with normal behavior?

 

[flydev]

I installed a setup with 10.6.11-MariaDB, Duplicator v1.4.21 and did a backup/restore from a utf8mb4 => utf8(mb3). It went good, no problem so far.

For information, utf8mb3 is an alias of utf8 on MySQL where on MariaDB is spelled utf8mb3 for less confusion I want to say. So utf8mb3 == utf8 (Will be deprecated soon after MySQL 8 ).

Also, you should check what @dragan suggested, and I was wondering if your setup is a multilanguage setup ? It could be a hook or even a module maybe.

You could also try to spot the issue by exporting the distant bugged database and importing it on your local dev setting the same charset (utf8/utf8mb3) and see his behavior.

Checking/diff the .sql distant/local files with, for example, Beyond Compare (trial test is ok) or MySQL Workbench

Edited May 11, 2023 by flydev
@dragan post // debugging tips

[torf]

OPening page 3 works directly. But when I try to access another tab I get the next warning about templates. Funny thing - this time the Problem is on page 8.

And the same page on my dev site:

I've tried with advanced mode and it looks just as it's supposed to look. But you are right. I do not use multi-language (only a german translation) but a couple of modules that do fiddle around with user rights ( Admin Restrict Branch and Page Edit Per User). But those modules are on both sites.

 

[flydev]

It's weird. Some suggested steps on what I would do if I were in your situation:

1. Check read/write permissions on the server => check
2. Clear browser cache, throwing a Modules Refresh and a Clear Compiled Files => test
3. Logging in admin on a incognito window => test
4. Disabling german language => test
5. Exporting the bugged database and whole files, importing it on local dev to test the setup => test
6. Upgrading Duplicator from dev-version branch, building a fresh package and restoring it again => test
7. Exporting from command-line the database and comparing the export file against the local dev version with a diff tool => check
8. Eating hot pepper ?️, sleeping and checking on next morning with a fresh ?
9. Reporting tests made here 

 

 

[WillyC]

but a couple of modules that do fiddle around with user rights ( Admin Restrict Branch and Page Edit Per User).

u.try disabble theese mods ( temproraley) to.see if 
is it?

[torf]

@flydev I'll start with 8 and see where it get's me tomorrow. ?

@WillyC I'll give it a try but first I have to bring the whole darn thing back to my dev Server. disabling the mods on production is something I wouldn't dare to. No idea if they may loose some settings and both are crucial for the site.

[torf]

So after going through the database for days without finding any suspicious entries I had a long talk with my client and it turns out - the error wasn't there in the beginning. So @flydev: duplicator is definitely innocent.

The error was a simple typo in production ready.php (they are both quite different so it wasn't too obvious). I had two lines with:

if(($page->template = "myTemplate")

But why this altered the output the way it did I have no idea.

[gebeer]

1 hour ago, torf said:

if(($page->template = "myTemplate")

with this code you are setting the template of the page to 'myTemplate'. You need to use == or === as a comparison operator

if(($page->template == "myTemplate")

EDIT: don't worry, we've all been there ?

[flydev]

What @gebeer said.

It explain everything - the typo was provoking an assignment to the page's template passed to this condition.

Good catch and thanks for getting back on this, bug killed?

 

[szabesz]

6 hours ago, gebeer said:

don't worry, we've all been there

Sure, until I bought PphStorm years ago, which spots this (and more...) and warms me right away.