Best practice forum (Archived)
La discussione è stata rimossa.
Hi Kevin,
That does seem strange. You might want to try setting a different cookie prefix:
https://totara.community/mod/forum/discuss.php?d=16936
To answer your question about the 'siteidentifier', this is a unique code which is used in various places (such as backup and restore to work out if you are restoring to the same site or a different one).
Simon
Hi Kevin,
Something else that would be helpful, could you try setting the debugging level to maximum then logging in while TEST is off and see if anything is output to the screen or to the error logs.
Simon
Yes it could be a problem. Looking at the code, the siteidentifier is just a random 32 character string with the HTTP_HOST appended to the end. It is initialised the first time it's requested and stored in the database for future use.
You could try changing it, but I'm not sure what unintended consequences there would be of updating an existing value. We would recommend manually installing the site rather than creating duplicates using VMs as you did.
I'd try looking at the error logs first as that might point to something more obvious being the cause.
Simon
To change the value, you'd need to manually modify the "config" database table. The format of the table is:
id | name | value
[id] | siteidentifier | hwyh0SeRv7YB2J61fBHJowfR9Xy3xKIqlocalhost
so some sql like this should do it:
UPDATE mdl_config set value = 'newvalue' WHERE name='siteidentifier';
Simon
just a thought - are you getting a db connection error? - are you running mysql?
if you're using mysql and - make sure the mysql users have the correct hostname set?
Have you changed the server configuration on the production VM to point to the new URL. For example if you are using apache you may need to alter the httpd.conf settings.
If you're getting a page not found error it suggests your not even getting as far as the code itself.
Simon
We've all done similar things Kevin :-)
While we're on the subject though there are a lot of references to the CFG->wwwroot value in the database - primarily in things like log files, generated links inside messages and so on. So if you were using this VM/cloning method for moving a site, while it would be fine for code, themes, user files and so on you would probably still have to make a backup of the database, use something like perl or sed to replace all the instances of the old URL in the .sql backupfile, then reimport into an empty database (with the right mysql user privileges set) on the new site.
Just something to bear in mind.
Or you can use the script at [site-name]/admin/replace.php - just make sure you backup your database first!
Simon
It goes through your database tables, replacing any instances of the the 'search' string you type in with the 'replace string. It only acts on 'varchar' and 'text' data field types though. by [site-name] I mean the web url (http://domain...).
You run it through the web interface by visiting the url, typically you'll need to be signed in as an admin.
Simon
I guess the best approach would be to store a placeholder in the database, something like '[[SITE_WWWROOT]]' then substitute it with the actual value after retrieving the database data but before displaying it.
The problem is that would need to be done anywhere that saves a site url in the database, which could include a whole lot of third party modules outside of our control. In principle though, that would make the database more portable.
Simon
Hi Kevin,
You say the page isn't loading...but which page? Have a look at the address bar in the browser - what URL is it trying to load exactly? There may be a clue there as to what is going wrong e.g. wrong host, wrong path, etc.
Also is the error a 404 "Not Found", a DNS lookup problem, or possibly a 500 apache configuration/server error?