HELP! Joomla backend has only header/footer after viewer access changes!

[lastevns]

Hey all, I'm really hoping someone can offer a fix quick for a sudden and perplexing problem.

When I went to bed last night, the back end of Joomla was working fine. Today, I wake up and go to the back end and everything under the top color bar is gone on ALL pages of the back end and in EVERY browser I try. Here's what the pages look like now:

backend_mostly_gone.png

I was working on Access Viewing Groups (reorganizing them) when I last had a working back end (that sounds so wrong... but I mean Joomla back end). Did that reorg cause this?

I can reinstall older saved files but I'd prefer to reinstall only what I must as I've made some serious content updates I don't want to lose.

PLEASE HELP. This is obviously a total work shutdown. THANK YOU!

PS -- I've learned this DID HAPPEN as a result of me ignorantly messing with the Viewing Access Levels and User Groups. I am now using that back end to the users area (administrator/index.php?option=com_users&view=users) and I am able to access everything under that panel. I obviously need to go back to the original user group and Viewing Access Levels I had before but I can't exactly recall what they were. Also, I can't access the Save & Close option so any changes I do make can't be saved. If anyone knows how to help, please pass this along. Thanks!

[lastevns]

For what it's worth, I went into my host (BlueHost) to restore and now my entire back end is white. Meanwhile, the front end of my site is now offline (though I never turned it offline as I can't even get into the Control Panel). So backend is now a blank page and front end is offline.

I went to my error logs and see this:

[04-Oct-2017 18:13:08 America/Denver] PHP Fatal error: Call to undefined method JApplicationSite::isClient() in /home2/xxxxxxxx/public_html/xxxxx/administrator/components/com_fields/models/fields.php on line 230

So I was thinking, maybe if I replace the core Joomla files I could get my site back up. But, when I compare the file above that is packed in the core files, it is written exactly as the current file is. So, a simple core replacement won't work, I don't think. The lines of code causing the fatal error reads,

// Implement View Level Access
if (!$app->isClient('administrator') || !$user->authorise('core.admin'))
{

And that same file in the newly downloaded package of Joomla 3.8 core files also reads,

// Implement View Level Access
if (!$app->isClient('administrator') || !$user->authorise('core.admin'))
{

So, doubting this can be fixed by a replacement of core files.

I believe this happened because I played with unchecking some boxes in the Special group -- when I realized I shouldn't do this, I was in the process of rechecking them when my Internet went down for hours (gotta love Charter). When it came back on, all of this mess began and I can't get in to the back end or control panel to reverse any of it.

Any help or advice would be appreciated.

[7EIRISH]

The settings if changed are not going to be recovered by replacing the files unless its the configuration.php file, which permissions are not. Do you have a backup of the database? I would try a complete backup of both files and data on a test install to see if you can get back to where you were.


Always make both data and file backups and label them with date, time and include a notes.txt file with, you got it!, notes, so you know what the backup means, before making any changes. Akeeba backup works great for this though I prefer to manually do mine.

Hope that helps.

Cheers!

[lastevns]

Hi. Thanks for responding!

My host does daily, weekly and monthly backups of the site and the databases. I also make my own weekly backup of the site but not of the databases (something I will correct, following this). I have a backup of the site that I might try to resort to should all else fail. It's from 9/29 so I will lose some member activity. My fear is that even it won't correct this problem. I may need to start going back further in the database backup restore dates (my host's backup of dbs from last week or even last month).

I did restore the last known working database -- no dice. I still had a white page where the back end/control panel should be).

I also restored the entire site from the last known good backup of the site files (which was this morning at 5:45 a.m.). Again, no dice. I just went from a message saying the site was down (which it wasn't when I left it) to an error code reading: "JHtmlBehavior::polyfill not found." Also, the site is no longer attempting to access the site itself, now, when I type in the name of the site (songwritersguild.com), the URL that the browser ATTEMPTS to access is: "https://www.songwritersguild.com/xxxxx/ ... /index.php." So it appears as if the site is trying to reinstall itself.

If you can offer any more help, I'd appreciate it. Again, thanks for responding!

Laurie

[wojsmol]

Hi lastevns
Probably you restored Joomla! 3.7.5 files on top of Joomla 3.8.0 site. If you restore backup please make anther backup of the current situation (files and database) delete it and restore It from previous backup.

[lastevns]

Hi,

I have done a few replace/restore attempts. One was a restore of my Joomla site files (they aren't in the root). Didn't help. Then I did a full server restore of all files. That just took the front end of the site offline but fixed nothing.

As to 3.75 verus 3.8...I was at Joomla 3.8 prior to this morning (I've had it for at least a few days, if not longer). So when I restored files from 5:45 a.m. this morning, they would have been 3.8 files being restored over a 3.8 installation. All that happened when I did this was that my site went from being up on the front end -- and not on the back end -- to being offline completely.

I also went to Joomla.org (or is it .com?) and downloaded core files for 3.8 and installed those over the files there. Again, no luck. Now, instead of a message telling visitors the site is down, I get only, "JHtmlBehavior::polyfill not found."

Not even certain why songwritersguild.com is now forwarding to https://www.songwritersguild.com/xxxxx/ ... /index.php.

I am going to try to follow ictoptopus' instructions on addressing the above error code. If that fails to help, I am going to try to restore the site first from an older host backup of the site (from 9/29) -- though I can't recall if I had 3.8 installed then... so that's worrisome. If that fails, I may try an Akeeba restore from my own Akeeba backup of the site (also from 9/29). However, I've never had to do one of those, so, total finger crossing.

If all of that fails, I'll be searching for a programmer to fix this mess. The client should LOVE paying for that. Happy days ~

Any suggestions, advice or fixes please let me know.

Laurie

Hi lastevns
Probably you restored Joomla! 3.7.5 files on top of Joomla 3.8.0 site. If you restore backup please make anther backup of the current situation (files and database) delete it and restore It from previous backup.

[lastevns]

I forgot to say it, but thank you for your response.

Can you clarify what you mean by,

Hi lastevns
... If you restore backup please make anther backup of the current situation (files and database) delete it and restore It from previous backup.

?

I am confused by this. Are you saying I should delete my entire site and reinstall from saved version/backup of my site? Sorry, just confused.

Laurie

[wojsmol]

Yes specially if you restore to Joomla! 3.7.5 from 3.8.0. See this link https://www.akeebabackup.com/support/ak ... ccess.html

[lastevns]

Good link. Thanks. I will keep that link open for my next (and final self-help) step. I do have my backup already transferred to a drive. Also, I know where my Akeeba backups reside on my server and I still have access to all my files via FTP. So, I have a couple of methods of getting at the 9/29/17 backup.

First I am trying my host's version of the 9/29/backup. If that works, I can avoid transferring off all my files and using Akeeba and kickstart. But, basically, this is a real nightmare. If you know of any trusted very reasonably-priced programmers who might fix this, please let me know.

Thanks again!

Laurie

PS - Wondering if I should have posted to the installation forum now. Though the problem didn't start as that, it seems to be one now.

Yes specially if you restore to Joomla! 3.7.5 from 3.8.0. See this link https://www.akeebabackup.com/support/ak ... ccess.html

[wojsmol]

We can fix this on forum but first step in do a proper restore, the we have a working site and can go from there. access levels issue was easy to fix really.

[roaminpizza]

In some cases the backend module edit doesn't work or shows a white screen after upgrading the new version of Joomla. In that case you can make the use of some javascript for module editing was modified, however the browser being used is still using the old cached version of the javascript which no longer works.

[lastevns]

Thanks for that. Unfortunately I'm in waiting mode trying the next restore. I will write back when I have a site restored. I can really use the help. Getting discouraged here.

Thanks again. Will follow up when I have a working restore.

We can fix this on forum but first step in do a proper restore, the we have a working site and can go from there. access levels issue was easy to fix really.

[lastevns]

We can fix this on forum but first step in do a proper restore, the we have a working site and can go from there. access levels issue was easy to fix really.

Just to clarify: If I end up using Akeeba and kickstart to restore a .jpa backup of my site, I should first remove EVERY file on my host server?

Or, alternately, should I only remove every file in the directory that holds my site (again the site isn't in the root directory).

And if I use the Akeeba restore method, will the database be compatible only with 3.8? This might be an issue if my .jpa is from the version prior to 3.8.

[wojsmol]

Detely only files related to website with problem and the same for database. If you have a full backup from Akeeba there shroud be database backup from the same moment in time.

[lastevns]

In some cases the backend module edit doesn't work or shows a white screen after upgrading the new version of Joomla. In that case you can make the use of some javascript for module editing was modified, however the browser being used is still using the old cached version of the javascript which no longer works.

Sorry. I'm not familiar with javascript other than to use small scripts and personalize them. As to browser... I've tried using FF, MSIE, Edge, Chrome and Safari. Same result on each.

Not quite certain what you're suggesting here. Don't mean to be thick but, can you clarify?

[lastevns]

Detely only files related to website with problem and the same for database. If you have a full backup from Akeeba there shroud be database backup from the same moment in time.

Are you saying Akeeba takes a backup of my database and includes it in the .jpa?

Or do you mean that there will be database backup created at the same time the .jpa was made but it won't be included in the .jpa?

[wojsmol]

@lastevns Please concentrate on my intrusion then we have grated success cleanse

Are you saying Akeeba takes a backup of my database and includes it in the .jpa?

If you don't exclude database from backup then yes.

[lastevns]

@lastevns Please concentrate on my intrusion then we have grated success cleanse

Are you saying Akeeba takes a backup of my database and includes it in the .jpa?

If you don't exclude database from backup then yes.

Hate to bother again but... have to...

On the link you sent earlier the directions read, "Here's the bad part. Since it went sideways during a major upgrade, you have to manually delete all the files and drop the tables."

What does it mean to "drop the tables?" Is this something I need to do to alter my database? If so, when and where do I make these "drops?"

Thanks!

[wojsmol]

You can simple create new database in hosting control panel and use details of this database during the restore process.

[lastevns]

You can simple create new database in hosting control panel and use details of this database during the restore process.

Yeah, I can recall doing this when I set up a local installation with XAMPP. I don't think I ever got the database working correctly though so I eventually got rid of XAMPP. Hopefully it will go correctly this time.

I wonder if you can answer this question: I have Joomla installed in a directory located within my public_html (or root) directory. I did not install Joomla at my root. So can I trust just removing the Joomla files in the directory in which I've installed Joomla? Or does Joomla, in its installation process, place any folders/files outside the directory in which its installed? In other words, do I need to go outside my Joomla directory to my public_html/root folder and get rid of any files or folders in the root?

Thanks, again!

[lastevns]

Thanks to all who helped. Turned out that my LAST attempt at a restore was the best. It worked perfectly and I only lost about half a week's content and members. I'll have to add those back. But, @wojsmol was correct about using my Akeeba backup. I first copied over all the files from my site directory to my laptop. Then I deleted all those files within my site's directory, leaving it empty. Then I uploaded the kickstart script and .jpa backup and followed the on screen prompts for a perfectly-working site (with none of the Access Viewing issues that started all of this). I did have a few worries about creating the new database -- mostly I couldn't recall if I'd set up Akeeba to keep my database or not -- but it was there, thank god.

I don't know why I didn't begin my restore using Akeeba. It was so easy. If this ever happens again, I'm beginning my restore process with my Akeeba backup.

Again, thanks to all who replied -- especially @wojsmol!

One final thing if anyone is reading this: Is there documentation for handling Access Viewing Groups? A JomSocial guy said I had too many. But I don't want touch them again for fear of breaking my site. Thanks!