Jump to content

superuser is missing rights


torf
 Share

Recommended Posts

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

1264247683_Screenshot2023-05-11081658.jpg.4fb537f8f8077ae7ef4a3c0dfa0dacdf.jpg

(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?)

Link to comment
Share on other sites

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 by flydev
precision
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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:

image.png.ed2a5c65492e966535bca0fb01b5e240.png

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?

 

  • Like 1
Link to comment
Share on other sites

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 by flydev
@dragan post // debugging tips
  • Like 1
Link to comment
Share on other sites

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.

1063751643_Screenshot2023-05-11165332.thumb.jpg.31a917f6f55f2e181d6b6bd9acee8004.jpg

And the same page on my dev site:

1438650925_Screenshot2023-05-11165217.jpg.9812968184bd62bf388d712aa73741d6.jpg

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.

 

Link to comment
Share on other sites

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 

 

 

Link to comment
Share on other sites

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

  • Haha 1
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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 ?

  • Like 3
Link to comment
Share on other sites

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