Dashboard dissappeared

Permalink
Last night I successfully added content to my website.

Tried logging in to the dashboard today and can't get access. Website running fine. But can't access dashboard or Edit bar.

I have
<?php Loader::element('header_required'); ?>
in my header.php page.

 
ryan replied on at Permalink Reply
ryan
Try manually removing your cache files. Log into the server and manually remove all contents of /files/cache/ and /files/cache_objects/

Do you have any files overridden - like single_pages/login.php or:
controllers/login.php
zeetron replied on at Permalink Reply
I have emptied both files/cache and files/cache_objects but the situation remains the same.

I haven't overwritten single pages or controllers in the root directory unless you refer to these folders in the concrete directory, which haven't overrided in any way..

No I haven't. Would trying the database source help and what table would that be?
ryan replied on at Permalink Reply
ryan
So, a couple more options here:

Uninstall the testimonials package (no idea why this would have any effect) manually from the database.

Take a look at the Packages table, then copy the values of the row that has the testimonials package in it, then delete that row. Add it back if it doesn't help.

Fix the javascript errors that are on the front side of this site. Not sure why this would matter either since none of them are loaded when trying to log into the dashboard.

Check file permissions on all of the files in your site - mainly everything inside of the /concrete folder. basically make sure the web server has read access to them.

upgrade from 5.3.3.1 to current stable (5.4.0.5) we've fixed allot of bugs since then and it's generally better.

You may also want to test that php's sessions are working. In your site's footer print out var_dump($_SESSION); See what changes when you try and login. Also print out
$u = new User();
echo var_dump($u);

on the login single page:
/concrete/single_pages/login.php

Are you on a cloud server by chance?
zeetron replied on at Permalink Reply
What's a cloud server?
ryan replied on at Permalink Reply
ryan
If you wanted concrete5 to run slow and require special configuration you'd host it here:
http://www.rackspacecloud.com/

- you're most likely not on a cloud server unless you specifically were shopping for a cloud hosting setup.
zeetron replied on at Permalink Reply
I'm going to attempt to upgrade to concrete 5.4.0.5

The last time I tried an install for this the results weren't satisfactory.

However, given no choice I will back up my data and proceed.

I may have to create a directory labelled concrete5.4.0.5 in the root to house the fresh install just in case. Tell me what you think.

By the way is prototype.js one of the javascript libraries installed by default in the concrete5 framework?
ryan replied on at Permalink Reply
ryan
This problem may very well be related to your sub-directory -> root level move that you did.

I looked at your cookie path and it was being set to / as it should be. Try commenting out the BASE_URL and DIR_REL lines from your config/site.php

Also if you upgrade, back it all up like you said, but don't do the upgrade in a sub-directory, I think that'll just cause more problems. back up the database, then rename your current concrete directory to concrete5.3.3.1 and then rename the new concrete directory from concrete5.4.0.5 to concrete and immediately pull up the upgrade script:
/tools/required/upgrade
zeetron replied on at Permalink Reply 1 Attachment
I've already moved all the contents of concrete5.3.3.1 to the root of my web server. Which indicates that its virtually empty hence the DIR_REL lines were set to "/" in my config/site.php file.

To upgrade to 5.4.0.5 are you suggesting I re-create the directory 5.3.3.1 again and then return all data elements back to this folder just before downloading & installing concrete5.4.0.5 ?

Will both directories 5.4.0.5 and 5.3.3.1 be in the web root, prior to pulling up the upgrade script /tools/required/upgrade?

Attached is a snapshot of what my directory looks like now.

I have also attempted commenting the lines in config/site.php file but it made no difference.
Mnkras replied on at Permalink Reply
Mnkras
remove the / in the rel dir
zeetron replied on at Permalink Reply
I don't have a forward slash there.

I have;

define('DIR_REL', '');

on line 7 which should be correct I think.

However I still can't log on to the dashboard.
zeetron replied on at Permalink Reply
Hi Ryan,

As you instructed I have upgraded to 5.4.0.5 and it was very successful. However I can still log in, but not to the dashboard and neither does the edit bar appear.

This means (as you are well aware) that I'm unable add or modify content.

I must also mention that there were some error messages that showed up on upgrade which didn't affect the sites' performance but could be worth mentioning.
Warning: Unknown: open(c:\windows\temp/sess_6pbemfsg2lvugnk7iao6n358h7, O_RDWR) failed: No such file or directory (2) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\windows\temp) in Unknown on line 0


I've tried setting permissions to concrete/single_pages/login.php to 755 or 775 and I get the following message on browsing;
"Access Denied" or "A file permissions error has occurred. Please check the permissions on the script and the directory it is in and try again."

Permission settings are set on 644 for concrete/single_pages/login.php and it reverts to these settings whenever I attempt to change them.


However I would like to know what the permissions on these single_pages folder and their respective subfolders should be? What else can I do resolve this dilemma.

Regards
ryan replied on at Permalink Reply
ryan
Session storage directory permissions.

Make sure c:\windows\temp/ exists and the server can read/write from that directory. You can open a window an explorer window and watch files get created and removed.

Another option would be to move servers. If you're using this in a production environment a linux based server would work much better.
zeetron replied on at Permalink Reply
The website in question is hosted on a Linux server by my web hosting company.

They have dual server environments for each hosted domain with a choice to run either Linux or Windows.

If this is a hosting issue, would you be kind enough to elaborate or tell me precisely what information to convey to my hosting company so that they can speedily resolve this permissions issue.

In the meantime I will present the error aforementioned to them.

Thanks
ryan replied on at Permalink Reply
ryan
This is definitely a windows only file path:
Warning: Unknown: open(c:\windows\temp/sess_6pbemfsg2lvugnk7iao6n358h7, O_RDWR) failed: No such file or directory (2) in Unknown on line 0
Warning: Unknown: Failed to write session data (files).

And if php's sessions are not working, that would certainly explain your inability to log into the dashboard.

Have your web host verify that your php session.save_path is correct and php's session management is working.
zeetron replied on at Permalink Reply
I got my web hosting company to look into it and they have. It now works. I can now log in.

They rectified it and told me to comment or remove the line
session.save_path = c:\windows\temp


from my php.ini file which had been there from the commencement of my project.

I am totally relieved, however after clearing my cache I noticed that the dashboard in 5.4.0.5 appears to be a lot slower, but I'll take that over not being able to log in any day.

Once again Ryan, many thanks for your generosity and help. Very much appreciated.

Thanks
Celdecea replied on at Permalink Reply
Not sure if this is related to your problem, but I had an issue with the edit bar not appearing on all but my home page when using "/". I had my concrete5 site in a subfolder off the web root and pretty URLs were enabled.

In my case, the subfolder was called "/new", so I tried changing the url from example.com/videos to example.com/new/videos. The edit bar reappeared.

Turned out to be a cookie path issue, but that's another story.