Install not installing or activating modules.

mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Tue, 2004-09-14 03:59

I just did an install from CVS. During the install I choose to check all modules and then activate. I get a success message on all but GD.

Then when I go to site admin -> Modules none of them are installed or active. If I click through each one then they install and can be activated. This used to work (maybe a week or so ago is when I noticed the change).

Perhaps it's related but when I install any module that requires configuration (like netpbm) after I configure the module I end up being logged out and have to login again to active the now-configured module.

While it doesn't actually break anything it sure is a pain.

-mg

 
baschny
baschny's picture

Joined: 2003-01-04
Posts: 328
Posted: Tue, 2004-09-14 08:31

mgrant, do you get any other error or warning message during the install? If you could re-do the install and note anything that might happen during the process, it might be helpful.

What OS/PHP Versions are you using? What Webserver is this running on?

The "Logging out" only happens in this situation, or are there other places where you are suddenly "logged out"? Do you have any warning or error message reported?

Thanks!

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Wed, 2004-09-15 00:05

I'm running on Windows Server 2003 using IIS6 and PHP 4.3.9RC2 in CGI mode. I'm also seeing the same results on WinXP / IIS5 / PHP 4.3.8

Each time I install do the following:

1. Drop the gallery database.
2. Empty the gallery2 directory
3. Empty the g2data directory
4. Update from CVS
5. Copy updated files to gallery2 directory
6. Create the gallery database
7. Launch the setup by navigating to http://localhost/gallery2

I'm going through that process right now to be sure I don't miss anything and I notice that on step 1 I get a warning from PHP that says:

Quote:
Notice: Undefined index: DOCUMENT_ROOT in c:\gallery2\install\steps\AuthenticateStep.class on line 86

During the system check I get a warning:

Quote:
Warning: Your PHP is configured to limit the memory to b (limit_memory parameter in php.ini). You should rise this limit to at least 16Mb for proper Gallery operation.

This is despite these two lines in my PHP.INI file:

Quote:
memory_limit = 32M ; Maximum amount of memory a script may consume (8MB)
limit_memory = 32M ; I put this in thinking that perhaps Gallery did not like memory_limit

The warning text suggests changing limit_memory but there is no such configuration directive.

On step 8 of the install I'm choosing "check all" and then "activate selected modules". This returns much too quickly (about 5 seconds) with several messages that say:

Quote:
Activated the <module name> module succesfully

Where <module name> is the name of the module selected in the previous step.

When I login and go to "site admin" -> "modules", there are no installed modules. They are all listed with links to install.

When I click the install link for ffmpeg (or any other configurable module) the link changes to "configure". I then click "configure" and get the configuration screen where I proceed to fill that out and click "Save Settings". This immediately logs me out and I'm back at the main page.

When I log back in I see that the module is installed and configured and I simply activate it. It seems that most everything else is working OK (with the exceptions I've noted in another thread about unit tests).

What I find troubling about this issue is that it's cropped up sometime recently. This same process worked some time ago.

I am uncertain if I am unexpectedly getting logged out elsewhere. I'll need to do some more testing to know for certain but I don't remember it happening.

Other than the warning notices I mentioned above I get no errors/warning/messages.

Let me know if there is something you'd like me to try.

Thanks,

-mg

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Thu, 2004-09-16 04:01
mgrant wrote:
Notice: Undefined index: DOCUMENT_ROOT in c:\gallery2\install\steps\AuthenticateStep.class on line 86

Hrmph. It seems that IIS doesn't have this environment variable. Can you provide your phpinfo output so that we can see what alternative variable to use?

mgrant wrote:
During the system check I get a warning:

Quote:
Warning: Your PHP is configured to limit the memory to b (limit_memory parameter in php.ini). You should rise this limit to at least 16Mb for proper Gallery operation.

This is despite these two lines in my PHP.INI file:

Quote:
memory_limit = 32M ; Maximum amount of memory a script may consume (8MB)
limit_memory = 32M ; I put this in thinking that perhaps Gallery did not like memory_limit

That's very odd! Look in your phpinfo output near the top and it'll tell you where it's looking for the php.ini -- it's a common error to edit the wrong php.ini. You're pretty experienced so this is probably not your problem but I have to ask, just in case :-) We can check your phpinfo output to see if the memory_limit is actually getting set in the "local values" column, though.

mgrant wrote:
On step 8 of the install I'm choosing "check all" and then "activate selected modules". This returns much too quickly (about 5 seconds) with several messages that say:

Quote:
Activated the <module name> module succesfully

Where <module name> is the name of the module selected in the previous step.

When I login and go to "site admin" -> "modules", there are no installed modules. They are all listed with links to install.

It's possible that they are all erroring out and we're somehow swallowing the errors. That's pretty weird though because we don't do the activation step unless they were all successfully activated.

The only scenario that I can think of which would account for this is the case where the module settings were cached in the g2data directory, but you blew that away. Is there any chance that it's using some other g2data directory that still has cache files in it?

mgrant wrote:
When I click the install link for ffmpeg (or any other configurable module) the link changes to "configure". I then click "configure" and get the configuration screen where I proceed to fill that out and click "Save Settings". This immediately logs me out and I'm back at the main page.

When I log back in I see that the module is installed and configured and I simply activate it. It seems that most everything else is working OK (with the exceptions I've noted in another thread about unit tests).

What I find troubling about this issue is that it's cropped up sometime recently. This same process worked some time ago.

I am uncertain if I am unexpectedly getting logged out elsewhere. I'll need to do some more testing to know for certain but I don't remember it happening.

Man that is very weird. I think that we need to get a developer onto an IIS box and see if they can reproduce this.

As a sanity check, would you be willing to install Apache+PHP on the same box and see if you can reproduce the problem with it? It would be helpful to be sure that this is an IIS issue and not just some weirdness with your overall configuration.

 
baschny
baschny's picture

Joined: 2003-01-04
Posts: 328
Posted: Thu, 2004-09-16 06:26

For the record, the DOCUMENT_ROOT warning is fixed, and the memory_limit check now handles this situation of --disable-memory-limit (like we have in the Win32-binary)...

About the IIS things, I need to try out G2 with PHP as CGI, I have just tried different PHP versions and IIS running in ISAPI-mode.

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Thu, 2004-09-16 14:03
Ernst wrote:
For the record, the DOCUMENT_ROOT warning is fixed, and the memory_limit check now handles this situation of --disable-memory-limit (like we have in the Win32-binary)...

About the IIS things, I need to try out G2 with PHP as CGI, I have just tried different PHP versions and IIS running in ISAPI-mode.

I'd prefer to run PHP in ISAPI mode but I've not yet been able to get it to work reliably with "slashargs". IIS tries to open the argument as a folder.

For example:

http://localhost/gallery2/phpinfo.php

works fine, but:

http://locahost/gallery2/phpinfo.php/arg1

fails because IIS tries to find

C:\Gallery2\phpinfo.php\arg1

which, of course does not exist. Using PHP in CGI mode allows the above example to work and thus the short URL feature can be made to work (I still have to tweak /gallery2/modules/core/classes/GalleryUrlGenerator.class because I don't have a REQUEST_URI and the "failover" condition does not account for PATH_INFO. Will someone please fix that?)

Ernst, do short URLs work for you with PHP-ISAPI/IIS?

Thanks,

-mg

 
baschny
baschny's picture

Joined: 2003-01-04
Posts: 328
Posted: Thu, 2004-09-16 14:23

mgrant, I haven't tried short URLs on ISAPI/IIS, neither have I tried out CGI/IIS at all.

I have just incorporated the changes you proposed in this other thread and will test it with it tonight in both modes, let's see what we find out.

Thanks for your help!

 
baschny
baschny's picture

Joined: 2003-01-04
Posts: 328
Posted: Thu, 2004-09-16 14:24

I just found out this interesting bug-tracker of PHP:

http://bugs.php.net/bug.php?id=7782

The >3 year old bug seems to be finally fixed in PHP5 RC3 but doesn't seem to have been commited to the PHP4-branch yet.

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Thu, 2004-09-16 17:59

Ernst,

Yes, I had found that in my research on the issue also. Unfortunately at the time I tried it PHP5 failed miserably. This morning I revisited 5.0.1 with IIS6 and found that in ISAPI mode I can get shortURLs to work. I can also run the PHP unit tests without having to comment out the include to security.inc. Unfortunately several of the tests fail. They may also fail in PHP4 and/or CGI mode I haven't had time to test yet.

Thanks,

-mg

UPDATE:
I just tried the phpunit tests in both PHP4.3.9RC3 and PHP5.0.1 and I'm getting the same results. This is excellent! I'm now planning on including PHP5 more in my tests. What this means is that I can now use the ISAPI module instead of CGI.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2004-09-17 07:04

What unit tests are failing? Can you save the HTML output and post it somewhere? Thanks.

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Fri, 2004-09-17 13:55

bharat,

Please see http://mgrant.dyndns.org/gallery2/failed_unit_tests.htm

TestConcurrentReadWrite failed the first time but when I reran failed test it succeeded.

Let me know what else you need.

Thanks,

-mg

 
baschny
baschny's picture

Joined: 2003-01-04
Posts: 328
Posted: Fri, 2004-09-17 14:15

mgrant, could you try out that TestConcurrentReadWrite a couple of times and see if you get another FAIL, and send me the reported problem when this is the case? Or haven't you had any other FAIL on that since then?

The other problems seem rather easy to fix, I will be fixing the testTranslate issues when I have some time. It looks to me that you don't have gettext enabled in your PHP, is that correct? Could you generate a phpinfo() page for this system?

On the migration issues I pass... Jesse? :)

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Fri, 2004-09-17 15:12

Ernst,

This morning I reran TestConcurrentReadWrite on the box it had failed. I ran the test 10 time and all 10 succeeded.

I also attempted to run in on my 2003 server. The tests die at testAddSmallPhotoToAlbum so I never get to the TestConcurrentReadWrite test.

The same thing was happening at TestDeactivate but I commented out all the code in the TestDeactivate function (in AdminLayoutsControllerTest.class) and it skips past it. I didn't want to muck around too much because I really don't know what I'm doing.

Oh, and I do not have gettext support in PHP. Is that a compiled-in option or can I change something in the PHP.INI to enable it? I didn't think it was required.

Thanks,

-mg

 
baschny
baschny's picture

Joined: 2003-01-04
Posts: 328
Posted: Fri, 2004-09-17 15:18

mgrant, gettext support is only required if you want to display your gallery in different languages: The translation is done by php's gettext extention. It probably comes with the Win32 binary, you can enable it in php.ini (php_gettext.dll or something). Our phpunit tests should be able to handle the situation without gettext thou when this little problem is fixed.

About it dieing at a certain test, do you have some output ("Fatal error" or other stuff) when this happens? Usually this kind of comment will get printed on the TOP of the "PASS/FAIL" table, so it's easy to miss. Check out if there is something (or open the result in the browsers "View->Source").

Cheers,
Ernesto

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Fri, 2004-09-17 16:36

Ernst,

You are correct! I had missed the error at the top.

Quote:
Fatal error: Call to undefined method AdminLayoutsTestPlatform::realpath() in c:\gallery2\modules\core\classes\GalleryStatus.class on line 483

Which I fixed (I think) by modifying line 483:

Quote:
$base = $platform->realpath(dirname(__FILE__) . '/../../../') . '/';

to this:

Quote:
$base = realpath(dirname(__FILE__) . '/../../../') . '/';

I don't really know what the implications are but the test now passes.

Thanks,

-mg

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-09-17 16:47

Your change should have allowed it to successfully print an error message, not made the test pass.. that's odd. I'll fix the AdminLayoutsTestPlatform class so you won't need that change in GalleryStatus.

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Fri, 2004-09-17 17:39

mindless,

First let me mention that I'm new to PHP (and development in general so forgive my ignorance but...

Why does gallery define the function realpath when it's a PHP function?

For example, in ItemEditLayoutPluginTest.class I see:

function realpath($path) {
	return realpath($path);
}

So, wouldn't it be simpler to just directly call the PHP realpath function?

And, regarding the change I made; doesn't it remove the dependency on a gallery defined realpath function and just use the PHP realpath function?

Sorry if these questions are obtuse but I'm learning as I go. Hopefully my learning experience is providing some value to the project.

Thanks,

-mg

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-09-17 17:55

the idea of the class GalleryPlatform is to make Gallery platform (Windows, Unix, ...) independent.
so all platform related functions should be methods of GalleryPlatform.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Fri, 2004-09-17 18:03
mgrant wrote:
Why does gallery define the function realpath when it's a PHP function?

We also define a ton of other functions that are PHP functions (fopen, fwrite, file_exists, ...).

There are several advantages to doing this.

  1. It gives us the option to "normalize" the platform under Gallery. Operating systems and PHP versions have subtle differences, and it's tedious to try to account for all of those in the code. By making all filesystem related calls go through our GalleryPlatform object, we have a choke point where we can control current and future platform quirks.
  2. It gives us debugging output so that we can see what's going on, even in logic that doesn't have its own debug tracing. Oftentimes this helps us find situations where we're trying to access the wrong file, etc.
  3. It gives us abstraction from the actual filesystem. This allows us to start thinking more ambitiously -- with this model it's possible for us to allow G2 to manage files on a remote system by just using a different GalleryPlatform instance. This might give us the ability to set up G2 master/slave instances in the future

[/]

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-09-17 19:31

I fixed the testgeneratehref failures that were in your unit test failures.
The test didn't work correctly when cookies are disabled.. were you testing without cookies?

 
mgrant
mgrant's picture

Joined: 2004-08-17
Posts: 100
Posted: Sat, 2004-09-18 01:42

mindless,

As far as I know I am using cookies. I'm using IE6 (in either XPsp1 or 2003) with what I think are default settings.

Anyway on both XP and 2003 testGenerateHref is now passing.

Unfortunately the tests are still dying at testAddSmallPhotoToAlbum.

It throws a PHP error:

Quote:
Fatal error: Call to a member function getId() on a non-object in c:\gallery2\modules\core\test\phpunit\ItemTest.class on line 938

Which, I think, might be a result of a previous failed test testAddMovieToAlbum

UPDATE (9/21):

This test appears to have been fixed and is no longer failing.