Hi,
I nedd to have access to session variables in config.php for some reasons. So I\m going to write session_start() somewhere in config.php.
Normally the session_start() function is called in lib/setup.php around the line 588.
Does anyone know that if starting the session earlier (as I said in config.php) may cause any problem or not?
Thank you in advanced.
What reason?
I want to choose the DB and moodledata based on a session variable.
calling session_start() in the config.php file would cause your page to be locked indefinitely: refer: http://in3.php.net/manual/en/function.session-start.php#69630
A better solution I guess would be to pass the database types and moodledata folder location as GET or POST variables and then modify $CFG->dbtype and $CFG->dataroot in setup.php itself using the variables.
Hope this was useful.
A better solution I guess would be to pass the database types and moodledata folder location as GET or POST variables and then modify $CFG->dbtype and $CFG->dataroot in setup.php itself using the variables.
Hope this was useful.
Hi Subodh,
I followed your link, but actually I don't want to have something like recursive sessions. I just want to put the session initializing forward.
Also I don't think using the GET or POST variables would be a good idea, cause (considering the GET variable) the required quarry string is not added to every links on every pages automatically.
So, as I said, it seems that I have to advance the session initializing. I just want to know if this cause any problem.
I followed your link, but actually I don't want to have something like recursive sessions. I just want to put the session initializing forward.
Also I don't think using the GET or POST variables would be a good idea, cause (considering the GET variable) the required quarry string is not added to every links on every pages automatically.
So, as I said, it seems that I have to advance the session initializing. I just want to know if this cause any problem.
Hi pedro,
What I meant to say was that, setup.php already calls session_start() by creating a new named session for Moodle. If you call a session_start() function in the config.php file, what will happen is that, your session_start() will work correctly but then the session_start() in the setup.php which is included by config.php, will cause the lock to occur indefinitely. That is where the problem (recursive session) will happen.
Ok, I had assumed you wanted this because you were passing data from another application other than moodle, thats why i suggested the GET mechanism.
The problem with doing what you want to do is that moodle initializes the database before the session (in case database sessions need to be used).
If youre sure that you'll use only file based sessions, you could cut the Moodle session initialization code (lines 554-592) from setup.php and paste them at the end of the config.php file.
This may work for you. Hope this was useful.
What I meant to say was that, setup.php already calls session_start() by creating a new named session for Moodle. If you call a session_start() function in the config.php file, what will happen is that, your session_start() will work correctly but then the session_start() in the setup.php which is included by config.php, will cause the lock to occur indefinitely. That is where the problem (recursive session) will happen.
Ok, I had assumed you wanted this because you were passing data from another application other than moodle, thats why i suggested the GET mechanism.
The problem with doing what you want to do is that moodle initializes the database before the session (in case database sessions need to be used).
If youre sure that you'll use only file based sessions, you could cut the Moodle session initialization code (lines 554-592) from setup.php and paste them at the end of the config.php file.
This may work for you. Hope this was useful.
Don't try to use Moodle's session for this.
If you really must do this (Like Howard, I would love to know why you need this) then use a separate cookie that you create manually just for this purpose.
If you really must do this (Like Howard, I would love to know why you need this) then use a separate cookie that you create manually just for this purpose.
Hi Tim,
Thank you for your comment.
I want to grant visitors of my site the admin privilege to move around and test the system. But I certainly don't want them to be able to modify/break my main site.
Also I don't want to setup 2 separate moodle. one of the reasons is maintaining one copy of code is easier and more reliable. the other reason is I don't want to WASTE about 60 MB of my disk space while there is an alternative to not to waste it and use a single copy of code.
So I want to put a "click to see the demo" link on the main moodle home page which links to demo.php.
the content demo.php is like this:
<?php
require_once('config.php');
if ($_SESSION['demo']) {
$_SESSION['demo'] = '';
} else {
$_SESSION['demo'] = 'demo';
}
redirect($CFG->wwwroot);
?>so I have to have access to session variables to be able to insert the following snippet in the config.php:
if ($_SESSION['demo'] == 'demo') {
$CFG->dbname = 'demo_db';
$CFG->dbuser = 'demo_dbuser';
$CFG->dbpass = 'demo_dbpass';
$CFG->dataroot = '/path/to/demo_data';
}
"Waste 60MB of disk space"
You're joking, right?
I haven't heard something like that since the 1980s!
Save yourself all the grief and install a second copy. People have header logos bigger than 60MB!!
You're joking, right?
Save yourself all the grief and install a second copy. People have header logos bigger than 60MB!!
Hi Howard,
you might be floating in the Gigabytes of space, but I'm in a situation that may kill people for just 1 MB (lol, joking).
Forget about the disk space. I don't want to maintain 2 separate copy on code.
One other reason of choosing this approach is that I found it artistic to have 2 working moodle using one url.
you might be floating in the Gigabytes of space, but I'm in a situation that may kill people for just 1 MB (lol, joking).
Forget about the disk space. I don't want to maintain 2 separate copy on code.
One other reason of choosing this approach is that I found it artistic to have 2 working moodle using one url.
I think that's why they invented version control software. This would be dead easy using 'git'. I'm a recent convert 
You can define a subdomain named demo and set its document root the same as your base domain (where your moodle code is).
then you can insert this code into your config.php:
Best wishes
then you can insert this code into your config.php:
if ( 'demo.example.com' == $_SERVER['HTTP_HOST']) {
$CFG->dbname = 'demo_db';
$CFG->dbuser = 'demo_dbuser';
$CFG->dbpass = 'demo_dbpassword';
$CFG->wwwroot = 'http://demo.example.com';
$CFG->dataroot = '/path/to/demo_moodledata';
}
this may not satisfy you enthusiasm to have the same url for different working Moodles, but address your need to have one single copy of code.Best wishes
Pedro,
On the long term, your approach will bring you more headaches than either using subdomains or having two Moodle instances. Think twice whether it is really worth it. Each of other solutions has its own beauty, artism if you will.
If you install using CVS, upgrading is fairly trivial and takes barely longer for two instances than for one, particularly that demo is not likely to have any customizations. If you really want a single instance, go with the subdomain variant.
On the long term, your approach will bring you more headaches than either using subdomains or having two Moodle instances. Think twice whether it is really worth it. Each of other solutions has its own beauty, artism if you will.
If you install using CVS, upgrading is fairly trivial and takes barely longer for two instances than for one, particularly that demo is not likely to have any customizations. If you really want a single instance, go with the subdomain variant.