Gossamer Forum
Home : Products : Gossamer Links : PHP Front End :

some template problems

(Page 1 of 2)
> >
Quote Reply
some template problems
I've got my templates mostly converted over to the PHP and v2.x format, so I'm starting to get to being able to offer more informed feedback... :)

I'm getting the following warnings and errors:

[27-Jun-2002 18:10:48] PHP Warning: SAFE MODE Restriction in effect. The script whose uid is 41925 is not allowed to access /path/to/cgi-bin/links/admin/templates/default_php/compiled/globals.txt.php owned by uid 98 in /path/to/www/pages/PHP/Links.inc.php on line 351

[27-Jun-2002 18:10:48] PHP Warning: file("/path/to/cgi-bin/links/admin/templates/default_php/compiled/globals.txt.php") - Success in /path/to/www/pages/PHP/Links.inc.php on line 351

[27-Jun-2002 18:10:48] PHP Warning: Bad arguments to join() in /path/to/www/pages/PHP/Links.inc.php on line 351

[27-Jun-2002 18:10:48] PHP Parse error: parse error in /path/to/www/pages/PHP/Links.inc.php(353) : eval()'d code on line 1

As you can see, they happen at the same time when viewing a page, but I think there is more than one problem there. I would guess the last three are related to running phpAdsNew within the page (I had similar eval() incompatibilities with phpBB's template parser), but the safe mode error looks to be separate. I didn't see this brought up anywhere else in the PHP forum, but it looks like another reason why the PHP scripts should not be installed in the cgi-bin...

Any way around it short of moving the /Links/PHP/ directory and changing all the include paths?

An unrelated question: I've read that any PHP code should work just fine in the templates, but it appears global variables cannot be defined within functions in the templates. Is this correct?

Thanks,
Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
In Reply To:
[27-Jun-2002 18:10:48] PHP Warning: SAFE MODE Restriction in effect. The script whose uid is 41925 is not allowed to access /path/to/cgi-bin/links/admin/templates/default_php/compiled/globals.txt.php owned by uid 98 in /path/to/www/pages/PHP/Links.inc.php on line 351

[27-Jun-2002 18:10:48] PHP Warning: file("/path/to/cgi-bin/links/admin/templates/default_php/compiled/globals.txt.php") - Success in /path/to/www/pages/PHP/Links.inc.php on line 351

[27-Jun-2002 18:10:48] PHP Warning: Bad arguments to join() in /path/to/www/pages/PHP/Links.inc.php on line 351

[27-Jun-2002 18:10:48] PHP Parse error: parse error in /path/to/www/pages/PHP/Links.inc.php(353) : eval()'d code on line 1

These errors are all due to the first error. Because PHP on your server's running in safe mode, scripts can't access files which are owned by other users. In this case, the PHP front end caches the converted Perl dumps of configurations, globals, etc. They are saved to file, but your webserver is saving them as owned by nobody (or whatever user the webserver is run as). That's fine, but then the script itself is owned by you and therefore doesn't match the user that owns the cached files.

In Reply To:
but it looks like another reason why the PHP scripts should not be installed in the cgi-bin...

That's got nothing to do with it being installed in the cgi-bin. Being installed in cgi-bin makes no difference unless your webserver is configured to treat everything in cgi-bin as a cgi script.

In Reply To:
Any way around it short of moving the /Links/PHP/ directory and changing all the include paths?

There's no need/reason to move those files. If you want to move page.php out of cgi-bin, just move that single file to whereever you want, and update the db_php_url setting in the admin.

In Reply To:
An unrelated question: I've read that any PHP code should work just fine in the templates

Yes, PHP code should work fine in the templates (remember you need to put the code inside <? ?>).

In Reply To:
but it appears global variables cannot be defined within functions in the templates. Is this correct?

Can you clarify on this? I'm not sure what you mean.

Adrian
Quote Reply
Re: [brewt] some template problems In reply to
Ok, I guess I misinterpreted the error(s). Given that, the cached templates obviously won't work as is for my setup... (Isn't it best to always assume PHP scripts will be running under safe mode for security purposes, similar to the reasons given for turning off register_globals?) Can that be turned off?

Moving page.php outside the cgi-bin did in fact solve that initial problem. I like that the PHP build location variable got added to the admin area (I last played with 2.0.5). Makes it easier to change such things. :)

I tried passing a variable to an include file containing a function, and grabbing that variable as a global, but it didn't work. If I passed it in through the function call, it did. For example, in very simple outline form:

home.html:

<?php $var = "yes"; ?>
<?include('include_menu.html')?>

menu.html:

<?php

function do_something($one, $two, $three) {
global $var;
....
}

echo do_something("", "", "");

?>

$var will have no value within do_something(). However, if I do the following it will:

<?php

function do_something($one, $two, $three, $var) {
....
}

echo do_something("", "", "", $var);

?>

Does that make more sense?

A few other questions that come to mind that I've only begun to test:

1) Is the <?include('include_xxx.html')?> syntax required for including templates within the Links system, or can things like <?php include_once('include_xxx.html'); ?> also function and still get program tags parsed within the included file?

2) I noted this when I first played with 2.0.5 and it made no sense at the time... When I set the 'cool' cutoff to top 30 and visit the what's cool page, it says it is showing the top 30 but actually shows a much different number, none of which should qualify. The actual number I'm seeing right now is 104.

3) Is the $Days_Old tag supported in Links SQL PHP v2.1.1? I thought it was a built in tag before, but I can't seem to find it mentioned anywhere. Where are the available tags defined?

Dan

p.s. I commented out the phpAdsNew lines and that did nothing to change the errors I was receiving, so you're probably right they're all related to user ownerships.
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
In Reply To:
<?php $var = "yes"; ?>
<?include('include_menu.html')?>
The scope in the templates actually isn't in the global scope, as the template is being included inside of a function. You would need to make that <?global $var = "yes"?>

1) It's possible, but isn't pretty and could possibly lead to never ending recursive calls to it. You would have to make a call to print_page() with the necessary arguments. If I get some time, I'll add a new function for this purpose, which also checks for recursion.

2) I'll have to look into this one.

3) It doesn't look like it's a built in tag for the Perl front end, so it won't be built into the PHP front end either.

Adrian
Quote Reply
Re: [brewt] some template problems In reply to
Quote:
You would need to make that <?global $var = "yes"?>
Is there a central place that explains which commands of that sort are available? I feel like I'm stumbling around in the dark and asking questions I should be able to find the answer to on my own...

1) I don't follow why an include_once() approach would lead to endless recursion, but I'll take your word for it.

2) I forgot to mention, when I encountered that problem previously, it "magically" went away on its own. I was 99% positive at the time I did nothing to "fix" it...

I don't know if it's related, but when I first visited page.php with the default templates after getting 2.1.1 up and running, the home page showed a very small number of links in each main category. The grand total display was correct, but only 19 or so were shown instead of ~2000. A few visits later, the correct number was showing, and I definitely did nothing there to change that.

3) I didn't think it was a plugin, but I'll have to look back at that and see if I can remember where it came from. Did you happen to have an answer as to where available tags for given templates are located?

Thanks,
Dan
Quote Reply
Re: [brewt] some template problems In reply to
I think I see where the problem lies regarding #2. Seems to be completely unrelated to the changing What's Cool counts of my v2.0.5 experience...

It appears what happened is that the database import from v1.1x v2.1.1 for some reason changed the isPopular entries. I confirmed that only 30 links had isPopular set to Yes in my v1.1x database, and 104 of them in the v2.1.1 one, with there being no pattern that I can see as to which ones were set to popular.

Anyone else witness this?

As far as what to do about it, I believe Alex answered that question in a previous discussion:

http://www.gossamer-threads.com/...?post=198119;#198119

I just did that, and it did indeed take care of the isPopular settings.

Any chance of adding that build option to the admin control panel? I suppose it doesn't really matter, as I'll have that done by a cron job once I get this up and running.

Dan
Quote Reply
Re: [brewt] some template problems In reply to
Quote:
These errors are all due to the first error. Because PHP on your server's running in safe mode, scripts can't access files which are owned by other users. In this case, the PHP front end caches the converted Perl dumps of configurations, globals, etc. They are saved to file, but your webserver is saving them as owned by nobody (or whatever user the webserver is run as). That's fine, but then the script itself is owned by you and therefore doesn't match the user that owns the cached files.

Any update on this? I'm pretty close to being ready to switch my 1.1x production installation over to 2.1.1 PHP, but without a workaround for safe mode, my error logs will become completely unusable.

Can a fix be made to either not cache those files or to do so in a manner that doesn't create ownership problems? By the way, I thought any file written by a script would run under my user id, so long as they were placed into a directory created by me (instead of by the script). I know directories written by the script are problematic under safe mode, but this is the first I've heard of the problem with files.

Quote:
The scope in the templates actually isn't in the global scope, as the template is being included inside of a function. You would need to make that <?global $var = "yes"?>

I tried that out of curiosity and it threw parse errors (expecting `','' or `';'') ... I tried a few variations:

<?global $var = $value?>
<?global $var = $value;?>
<?php global $var = $value; ?>
etc.

The only one that didn't throw an error was <?php global $value; ?>, but that didn't exactly do anything, either... Is there some trick to using the <?global?> tag?

Dan
Quote Reply
welcome to Dan's chop shop... In reply to
Adrian, are you on vacation by any chance?

I decided to try something to see if I could work around the safe mode restriction issue, and it seems to have accomplished that goal. In Links.inc.php, function read_conf(), I simply re-initiallized $cached_file_path to avoid grabbing the compiled file.

After the section that conditionally sets $cached_file_path's value, I added:

$cached_file_path = '';

I don't know (yet) if there any unforseen side effects of that, such as admin tmp directory issues, that won't be able to access the correct directories... On second though, it's probably better to overwrite $cached_file_path for only one condition, that of the templates directories. So, move that line right after:

Code:
if (!empty($cache_path) and (file_exists($cache_path) or @mkdir($cache_path, 0777))) {
$cached_file_path = "$cache_path/" . basename($config_file) . '.php';

Hardly a solution, but it seems to be an effective stop gap...

I also noticed my /compiled/globals.txt.php file is a very old copy, having made changes to globals.txt (mostly offline changes that I uploaded, if that makes a difference). What triggers that to be updated?

Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Sorry I haven't been replying to these messages, as I've been really busy with another projects Unsure.

In Reply To:
Any update on this? I'm pretty close to being ready to switch my 1.1x production installation over to 2.1.1 PHP, but without a workaround for safe mode, my error logs will become completely unusable.

In terms of modifying the code, there isn't anything I can do for you (that I know of) that won't be a huge performance hit (eg. disabling the caching). That's just one of the downsides of your ISP enabling PHP's safe mode. The PHP file is owned by you, yet the webserver runs as another user (eg. nobody), so anytime a PHP script creates a file, it can no longer access it (depending on their safe mode settings).

Without changing the PHP's configuration, the only way I can think of to get around this is to change the ownership of all the files the PHP front end needs to the same as the webserver.

In Reply To:
<?global $var = $value?>
<?global $var = $value;?>
<?php global $var = $value; ?>
etc.

The only one that didn't throw an error was <?php global $value; ?>, but that didn't exactly do anything, either... Is there some trick to using the <?global?> tag?

ughh, don't know what I was thinking there Smile, but it should be <?global $var; $var = "foo";?>

Adrian
Quote Reply
Re: [Dan Kaplan] welcome to Dan's chop shop... In reply to
In Reply To:
I also noticed my /compiled/globals.txt.php file is a very old copy, having made changes to globals.txt (mostly offline changes that I uploaded, if that makes a difference). What triggers that to be updated?

That's probably the globals.txt.php that it generated the first time you executed the PHP front end. Because of your webserver's configuration (PHP safe mode), it couldn't read/write to the file after that. It attempts to update that file when the globals.txt file is newer than the globals.txt.php file.

Adrian
Quote Reply
Re: [brewt] some template problems In reply to
Ah, good to see someon's home. It was getting kinda lonely around here. :)

Quote:
In terms of modifying the code, there isn't anything I can do for you (that I know of) that won't be a huge performance hit (eg. disabling the caching). The PHP file is owned by you, yet the webserver runs as another user (eg. nobody), so anytime a PHP script creates a file, it can no longer access it (depending on their safe mode settings).

Why can't a blank globals/language.txt file be set up in the compiled folder with the original distribution and made writeable? Wouldn't that solve the ownership problem? Simply give the compiled copy an old file date and it would get updated initially to the correct contents, right?

As it is, I can't even delete the current files without root access, so I'll have to ask that my host do that for me...

I think you would be doing a huge disservice to an otherwise fine program by giving up on safe mode functionality. As far as I can tell, that's a must for any responsible shared PHP hosting service.

Quote:
That's probably the globals.txt.php that it generated the first time you executed the PHP front end. Because of your webserver's configuration (PHP safe mode), it couldn't read/write to the file after that. It attempts to update that file when the globals.txt file is newer than the globals.txt.php file.

I see. So, it sees that my copy is newer than the compiled copy and uses mine, thus giving the impression that the latest globals file is being used correctly?

Dan

Last edited by:

Dan Kaplan: Jul 18, 2002, 7:26 AM
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
By the way, here's an alternative idea for approaching globals.txt and language.txt that might be simpler and more efficient overall: It appears the only difference between the .txt and the .txt.php (compiled) versions is the former is a Perl array and the latter is a PHP array. (I assume the efficiency of the cached copy you refer to is due to not having to convert the array format?) The only reason I can see to prepare globals.txt in Perl format is because that's what the admin area uses. If instead, an intermediate step was added in to convert the to and from the admin's Perl format before writing/reading to globals.txt in PHP format, it doesn't seem like there would be any need for the compiled copy.

After all, the end result of globals.txt and language.txt (.php) will get used thousands more times than the admin side of those same files, so why not approach it from the opposite side and do the conversion work before sending it out to the masses (much like building a static directory)?

Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Ok, I had my host delete the /default_php/compiled/ and /default_php/local/compiled/ folders and files. I recreated them manually and uploaded dummy copies of globals.txt.php and language.txt.php, making them writable. Visited several pages, checked the error logs, and no problems are apparent!

It doesn't look like Links is updating the compiled copy still, but now that I think about it, the copy I uploaded probably has a newer date than the non-compiled copy already on the server... Oops. :)

So, unless any unforseen problems spring up, it would appear that is a very simple and effective solution to the safe mode issues. However, it's one that can't easily be done by users after the fact, so it would need to be officially acknowledged by G-T as the way to go...

A related question: Are globals.txt and language.txt the only files that get compiled, or do any of the other templates also get that treatment? The reason I ask is because the /templates/admin/ and /templates/default/ folders seem to place a lot of additional files into the compiled folder.

Just to be safe, I added all the /default_php/local/ *.txt files to the /local/compiled/ folder, saved with .txt.php extensions. If they don't get used, no loss. If they do, well, better to have them owned by my user id in advance than having to bug my host again. :)

Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
In Reply To:
Why can't a blank globals/language.txt file be set up in the compiled folder with the original distribution and made writeable? Wouldn't that solve the ownership problem? Simply give the compiled copy an old file date and it would get updated initially to the correct contents, right?

hmm... good idea. I think that could work, although it isn't the nicest thing to put files into admin/tmp on a default install Unsure.

In Reply To:
As it is, I can't even delete the current files without root access, so I'll have to ask that my host do that for me...

Since you have cgi, just use fileman to delete the files, then upload (through FTP where it will set your permissions instead of the webserver's perms) empty replacements of those files.

Adrian
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Hi Dan,

Jumping in a bit late, just more of a comment on your ISP's setup:

Quote:
[27-Jun-2002 18:10:48] PHP Warning: SAFE MODE Restriction in effect. The script whose uid is 41925 is not allowed to access /path/to/cgi-bin/links/admin/templates/default_php/compiled/globals.txt.php owned by uid 98 in /path/to/www/pages/PHP/Links.inc.php on line 351


That seems crazy. Your setup means that if any php script creates a file, it can no longer even read the file?! Wouldn't most php scripts break under such situations (anything that requires creating files)? I would really talk to your ISP, as the user test here seems silly (like giving someone write access to a file, but not read access).

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] some template problems In reply to
I think there's a few things going on which confuses the issue. Normally, a file created by PHP is still readable (I know that first hand), so I'm guessing it has to do with running PHP scripts out of the cgi-bin without being specified to run as an Apache process (which I first thought was the problem). I think that would have to be categorized under abnormal uses of PHP...

Safe mode restrictions probably kick in because the cgi-bin on my host is set up to make any file contained within it executable by default. I would think that would interfere at some level with the write permissions and ownership.

Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Hmm, it would be worth testing. Try creating a simple test.php script that creates a test.txt file and look at who owns it. Is it owned by nobody if it's in the cgi-bin?

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] some template problems In reply to
I should be owned as nobody regardless of where it's created. I can't think of any exceptions to that... As to the read problems, I can only guess as to what's causing that. I believe that problem doesn't exist outside the cgi-bin, having worked with such files previously.

Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Read problems are due to PHP's safe mode turned on. See http://www.php.net/...atures.safe-mode.php for more info. The example given on that page is a good one:

Quote:
When safe_mode is on, PHP checks to see if the owner of the current script matches the owner of the file to be operated on by a file function.

This means, that the file that you created in the PHP script won't be readable as it's created and owned by nobody. You should really ask your ISP to turn down some of the safe mode settings as it's pretty useless, especially if you have cgi capabilities.

Adrian
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Quote:
I should be owned as nobody regardless of where it's created. I can't think of any exceptions to that... As to the read problems, I can only guess as to what's causing that. I believe that problem doesn't exist outside the cgi-bin, having worked with such files previously.


But if it's owned by nobody, then your php scripts can't read it because of safe mode. Hence the problems.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [brewt] some template problems In reply to
The PHP doc item Adrian quoted is interesting. The quote itself says nothing about the read problem, but the accompanying example does. I'm not sure why that problem hasn't been evidenced in other testing of mine... It's possible read functions are limited and include/require functions are not, although I see a user note says they also are.

However, I'm not sure why the resistance to working around the problem. As evidenced above by my proposed solution, it's easy to the point of trivial to do so. The best I can figure is that G-T would rather not set up the default files differently for the PHP front end than for the Perl one. Problem is, they're different in many practical respects and should be treated differently ... assuming you don't want to handcuff their functionality.

As I said above, safe mode is in place in shared hosting environments for security purposes. Why would a host who has researched the issue extensively want to change that because a single script is not willing to perform a simple workaround?

Dan
Quote Reply
Re: [brewt] some template problems In reply to
Quote:
turn down some of the safe mode settings as it's pretty useless, especially if you have cgi capabilities.

Could you expand on that a bit?

1) Why do you consider safe mode useless?

2) What does cgi capability have to do with the issue?

Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Well the purpose of safe mode is to make it so that you can't read other people's files and such (to improve on security). But what's the use if you have cgi capabilities where it doesn't restrict you? It's like putting a lock on the front door of your house, yet leaving the backdoor unlocked. Likewise, if you wanted to read /etc/passwd and PHP has safe mode on, then you can just use a Perl CGI to read it.

I don't really think it's totally useless, but in certain configurations, it's too restrictive making it impossible to code with. Just take the problem you're having right now with the cached files as an example. Yes, we have a quick fix, but it only works because there's only 4 files which are created by the PHP front end which always have the same file name. What would you do if it made many, many files where you didn't know the filename? You can't possibly create files to fix that.

In Reply To:
However, I'm not sure why the resistance to working around the problem.

Sorry if we sound like we're resisiting to working around the problem, but we really aren't. I'm willing to add those files to the package, but we're just trying to explain to you that the real source of the problem isn't our code, but PHP's safe mode.

Adrian
Quote Reply
Re: [brewt] some template problems In reply to
I understand safe mode is the root of the problem, but I disagree with:

Quote:
the real source of the problem isn't our code, but PHP's safe mode.

That's kind of like saying society commits the crime, not the individual... Sure, there are other elements at play, but we've got a known set of rules to work with. It makes more sense to work within that constraint than to blame the rules which we don't have control over.

Quote:
What would you do if it made many, many files where you didn't know the filename?

I would come up with a different approach... Could be a config file (like ConfigData.pm), database storage, who knows. It isn't really relevant here, but I also program for a living (PHP and MySQL) and am quite familiar with having to do things differently than I would prefer because they just don't work as well in practice as in theory.

I think I follow what you mean now by cgi capabilities providing ways to get around PHP's safe mode, but I don't think that's a relevant issue here, if nothing else because a well secured cgi-bin will make all files within it non-readable through the web (like I said above, my host makes everything in the cgi-bin executable by default, so good luck viewing it).

Dan
Quote Reply
Re: [Dan Kaplan] some template problems In reply to
Im just a newbie, but cant you just do a chown to change the owner, i just ran into the safe mode problem this morning and it fixed it...
> >