432
Hi,
Those permissions that Dave quoted for folders and files are spot on.
Quote:
As a general rule of thumb, yes, if it works on a lower CMOD, then by all means leave it as is.
Peter
Those permissions that Dave quoted for folders and files are spot on.
Quote:
theprof wrote:
I have actually checked my cache settings as they were..I was running 774, and it has been working .....so I guess I keep it there
As a general rule of thumb, yes, if it works on a lower CMOD, then by all means leave it as is.
Peter
433
Yes, the login and cookies would be an obstacle, not impossible I hope.
osCommerce, for just browsing and looking at products uses the cookie named 'osCsid' and XOOPS does similar with setting the cookie name 'PHPSESSID'
They both use additional cookies for logging in, and I assume the XOOPS/osC module would have to be checking all of them, in the case of someone ordering online.
osC does put the huge long session id in the url, even when browsing a website, and you have to turn session id's off for any bots/spiders, otherwise if the bot picks up the session id and it appears in search engines, then there is the 'chance' of 2 people logging on with the same session id (ouch !! ). osC handles this by turning off sessions for spiders though.
So, the whole session management is possibly done a bit differently to XOOPS maybe ??
Peter
osCommerce, for just browsing and looking at products uses the cookie named 'osCsid' and XOOPS does similar with setting the cookie name 'PHPSESSID'
They both use additional cookies for logging in, and I assume the XOOPS/osC module would have to be checking all of them, in the case of someone ordering online.
osC does put the huge long session id in the url, even when browsing a website, and you have to turn session id's off for any bots/spiders, otherwise if the bot picks up the session id and it appears in search engines, then there is the 'chance' of 2 people logging on with the same session id (ouch !! ). osC handles this by turning off sessions for spiders though.
So, the whole session management is possibly done a bit differently to XOOPS maybe ??
Peter
434
Hi,
Well, my XOOPS website has only been up for 5 days, but I have used most of the functions in admin, added links, changed templates, themes, done a fair bit with config. changes, and added various blocks of code (html wrapped in the necessary PHP code), changed meus, added menu blocks in manually.
So, as far as I know, this all works fine. The 644 is default permission on most servers, and even the previous hosts I was with, I used 644's for any PHP applications, osCommerce, Drupal, Mambo, phpwebsite and a few others.
Most FTP clients let you select all the files in a path, and then you can do a mass permissions change. If you are concerned, possibly try and change all the files that reside ina particular module first, try that module, and then if that works without errors, continue to change/test other paths.
Peter
Well, my XOOPS website has only been up for 5 days, but I have used most of the functions in admin, added links, changed templates, themes, done a fair bit with config. changes, and added various blocks of code (html wrapped in the necessary PHP code), changed meus, added menu blocks in manually.
So, as far as I know, this all works fine. The 644 is default permission on most servers, and even the previous hosts I was with, I used 644's for any PHP applications, osCommerce, Drupal, Mambo, phpwebsite and a few others.
Most FTP clients let you select all the files in a path, and then you can do a mass permissions change. If you are concerned, possibly try and change all the files that reside ina particular module first, try that module, and then if that works without errors, continue to change/test other paths.
Peter
435
Hi,
All my XOOPS PHP files are a 644, except for mainfile.php , which is a 444, and I may move that to a path outside of the webroot anyway.
The 644 is ........
user - read write
group - read
world - read
In theory, I would think that a PHP file, being a server side, would have to actually be executed (commands parsed by the server and returned to the client), however a read will suffice for the public (world).
Peter
All my XOOPS PHP files are a 644, except for mainfile.php , which is a 444, and I may move that to a path outside of the webroot anyway.
The 644 is ........
user - read write
group - read
world - read
In theory, I would think that a PHP file, being a server side, would have to actually be executed (commands parsed by the server and returned to the client), however a read will suffice for the public (world).
Peter
436
Hi,
Quote:
I don't know the problems that are being encountered, but do know that osC always uses a LOT of constants, so if XOOPS is the front end, then can XOOPS set the constants ?
Quote:
I guess the dual login issue is a lot to do with handing the different sessions.
Peter
Quote:
bd_csmc wrote:
it still has more integration that it needs to go through, esp concerning the dual login issue
I don't know the problems that are being encountered, but do know that osC always uses a LOT of constants, so if XOOPS is the front end, then can XOOPS set the constants ?
Quote:
http://au2.php.net/manual/en/language.constants.php
Like superglobals, the scope of a constant is global. You can access constants anywhere in your script without regard to scope. For more information on scope, read the manual section on variable scope.
Syntax
You can define a constant by using the define()-function. Once a constant is defined, it can never be changed or undefined.
I guess the dual login issue is a lot to do with handing the different sessions.
Peter
437
Hi,
I hope I have understood your needs. There is a site I look after and we have 3 domains on one website, and I use a small PHP script to check which domain it is, and then set various variables and constants, to control what is done. In fact I force the directory path to a specific language. Your case is slightly different, but I'm sure you can modify the script below, and then use the same script on each domain.
You will need to ensure though, that the script gets executed for EVERY other script that is run, this was easy for me, because the product I was using already had a script that was included with every other PHP file, so I simply added an include to point to the small script, which checked the domains.
Anyway, I made up a sample one, hope it helps .......
Peter
I hope I have understood your needs. There is a site I look after and we have 3 domains on one website, and I use a small PHP script to check which domain it is, and then set various variables and constants, to control what is done. In fact I force the directory path to a specific language. Your case is slightly different, but I'm sure you can modify the script below, and then use the same script on each domain.
You will need to ensure though, that the script gets executed for EVERY other script that is run, this was easy for me, because the product I was using already had a script that was included with every other PHP file, so I simply added an include to point to the small script, which checked the domains.
Anyway, I made up a sample one, hope it helps .......
<?php
// Constants prefixed with string "MLP" indicate Multi Language Pack constants
// If user comes to site with preceeding string "www." , remove it, not required
$httphostname = $_SERVER['HTTP_HOST'];
$hostname = str_replace("www.", "", $httphostname);
define('MLP_HOSTNAME', $hostname);
$domains['xoops.de'] = array(
'language'=>'de',
'domain_no'=>'1',
'partner_logo'=>'logo_german.jpg'
);
$domains['xoops.jp'] = array(
'language'=>'jp',
'domain_no'=>'2',
'partner_logo'=>'logo_japanese.jpg'
);
$domains['xoops.fr'] = array(
'language'=>'fr',
'domain_no'=>'3',
'partner_logo'=>'logo_french.jpg'
);
//Default to german language if not found
if (isset($domains[$hostname]['language'])) {
$language = $domains[$hostname]['language'];
$domain_number = $domains[$hostname]['domain_no'];
$logo = $domains[$hostname]['partner_logo'];
} else {
$language = 'de';
$domain_number = '1';
$logo = 'logo_german.jpg';
}
define('MLP_LANGUAGE', $language);
define('MLP_DOMAIN_NUMBER', $domain_number);
define('MLP_LOGO', $logo);
//Then set any other variables or constants needed for the Multi langauge pack
?>
Peter
438
Hi,
Quote:
Fromhttp://www.macambridge.com/dummies/
Quote:
So, you need it set to zero for no display of the right block.
Peter
Quote:
iolai wrote:
Any idea what makes the right block disappear, even that I have "$xoopsOption['show_rblock'] = 1;" in the wrap code?
Fromhttp://www.macambridge.com/dummies/
Quote:
How to wrap static HTML content in Xoops
The following applies If you wish to have a page of HTML content wrapped inside XOOPS without using a content module. This example works if you want the HTML content files to be located in the root of your XOOPS installation. First create a PHP file with the following content using your favorite text editor. Notepad for windows is suitable for example.
<?php
include("mainfile.php");
include("header.php");
$xoopsOption['show_rblock'] = 1; //0 for no right block
?>
Your HTML Code here (Note: Do not include head and body tags)
<?php
include("footer.php");
?>
So, you need it set to zero for no display of the right block.
Peter
439
I've used osCommerce quite a lot, not as an XOOPS module, but as a stand-alone E-Commerce system.
What is the problem with the XOOPS osC module ?
Peter
What is the problem with the XOOPS osC module ?
Peter
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | May 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|