From: Temlakos <tem...@gm...> - 2008-02-27 17:29:21
|
Markus: When you had issued release 1.0.1 of SemanticMediaWiki, the wiki that I co-administer was down--someone had compromised our web host's server, either with a faulty PHP upgrade or with a trojan; no one knows for sure. We have taken one month to get back on-line on a fully dedicated server--essentially a "virtual-private-server" physical host with only one virtual host, that being ourselves. And when I reinstalled our wiki and then installed SMW 1.0.1, not a single page with my custom data type "Historical Date" would load. They all would hang. (Pages not having this data type would not hang.) You will no doubt anticipate me and say that the Historical Date type was to blame. I might go along with that, except for one thing: the Historical Date datatype works without a problem in SMW 1.0, the version one step back. But when I try to include it with SMW 1.0.1, I get a problem. I invite you all to visit our wiki. Actually, this one salient feature appears to be the cause of a bad interaction with SMW 1.0.1: namely that we store most of our images, not on the wiki itself, but on a separate wiki, called the Media Pool. The reason for this is that we have content in English and in seven additional languages--and serving up eight identical copies of an image would produce an upgrader's nightmare and might also take up extra hard-disk space that we could put to better use. Here is the text of a file named "GlobalSettings.php" that we include with all the wikis that use this Media Pool: > <?php > # Shared Image POOL > $wgSharedDB = "pool"; > > $wgUploadNavigationUrl = 'http://creationwiki.org/pool/Special:Upload'; > $wgUseSharedUploads = true; > $wgSharedUploadPath = 'http://creationwiki.org/pool/images'; > $wgSharedUploadDirectory = > '/var/www/vhosts/creationwiki.org/httpdocs/pool/images'; > $wgHashedSharedUploadDirectory = true; > > $wgFetchCommonsDescriptions = true; > $wgSharedUploadDBname = 'jcreatio_pool'; # DB-Name of PoolWiki > $wgSharedUploadDBprefix = ''; # Table name prefix for PoolWiki > $wgRepositoryBaseUrl = "http://creationwiki.org/pool/image.php/Image:"; > > ?> You can see the variables that we set, and the sort of directories we set with them. The trouble seems to arise when we set an absolute directory path for the variable: $wgSharedUploadDirectory This is a fairly common technique, and we have used it successfully for years. That it should break now is something of a puzzle. If we can't figure out why SMW 1.0.1 breaks when I introduce a custom nonlinear data type, then we might not be able to do any more upgrades beyond 1.0. Terry A. Hurlbut <http://creationwiki.org/> |
From: Markus K. <ma...@ai...> - 2008-02-27 18:36:21
|
On Mittwoch, 27. Februar 2008, Temlakos wrote: > Markus: > > When you had issued release 1.0.1 of SemanticMediaWiki, the wiki that I > co-administer was down--someone had compromised our web host's server, > either with a faulty PHP upgrade or with a trojan; no one knows for sure. > > We have taken one month to get back on-line on a fully dedicated > server--essentially a "virtual-private-server" physical host with only > one virtual host, that being ourselves. > > And when I reinstalled our wiki and then installed SMW 1.0.1, not a > single page with my custom data type "Historical Date" would load. They > all would hang. (Pages not having this data type would not hang.) Oh, that is strange. So far SMW did not include the historical date anyway, so I cannot imagine what breaks there -- maybe you need some patch that was accidentally present in SMW 1.0 before (such as having the historical date in the language file)? The changes to SMW 1.0.1 were really minor, and it is certainly safe to copy language files from SMW1.0 if this helps. > > You will no doubt anticipate me and say that the Historical Date type > was to blame. I might go along with that, except for one thing: the > Historical Date datatype works without a problem in SMW 1.0, the version > one step back. But when I try to include it with SMW 1.0.1, I get a > problem. Strange, then maybe you can (partially) downgrade to 1.0. My plans are still to make Historical Date the new Date, which is why the datatype is not included yet. I will rather move its extended features over to Date as soon as I get down to it. > > I invite you all to visit our wiki. Actually, this one salient feature > appears to be the cause of a bad interaction with SMW 1.0.1: namely that > we store most of our images, not on the wiki itself, but on a separate > wiki, called the Media Pool. It seems even stranger that this should be the problem, since it seems to be so unrelated to one particular datatype. > The reason for this is that we have content > in English and in seven additional languages--and serving up eight > identical copies of an image would produce an upgrader's nightmare and > might also take up extra hard-disk space that we could put to better use. > > Here is the text of a file named "GlobalSettings.php" that we include > > with all the wikis that use this Media Pool: > > <?php > > # Shared Image POOL > > $wgSharedDB = "pool"; > > > > $wgUploadNavigationUrl = 'http://creationwiki.org/pool/Special:Upload'; > > $wgUseSharedUploads = true; > > $wgSharedUploadPath = 'http://creationwiki.org/pool/images'; > > $wgSharedUploadDirectory = > > '/var/www/vhosts/creationwiki.org/httpdocs/pool/images'; > > $wgHashedSharedUploadDirectory = true; > > > > $wgFetchCommonsDescriptions = true; > > $wgSharedUploadDBname = 'jcreatio_pool'; # DB-Name of PoolWiki > > $wgSharedUploadDBprefix = ''; # Table name prefix for PoolWiki > > $wgRepositoryBaseUrl = "http://creationwiki.org/pool/image.php/Image:"; > > > > ?> > > You can see the variables that we set, and the sort of directories we > set with them. > > The trouble seems to arise when we set an absolute directory path for > the variable: > > $wgSharedUploadDirectory > > This is a fairly common technique, and we have used it successfully for > years. That it should break now is something of a puzzle. Just as unclear for me, especially since SMW clearly separates its globals with "smwg" as a prefix, so there should be no accidental name clashes or the like. > > If we can't figure out why SMW 1.0.1 breaks when I introduce a custom > nonlinear data type, then we might not be able to do any more upgrades > beyond 1.0. As I said: SMW1.0 and 1.0.1 are largely compatible. Many files are just not changed, and the others can probably be exchanged one-by-one to track down the issue. Seeing your earlier contributions, I trust your technical skills for doing that :-) Markus -- Markus Krötzsch Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Sergey C. <sem...@an...> - 2008-02-27 21:53:54
|
Are there any problems reported in error log? Try to enable debug info and so on - I would guess that it's some PHP limit that you didn't re-enable in the new setup. Apache logs should tell you more. Sergey On Wed, Feb 27, 2008 at 1:36 PM, Markus Krötzsch <ma...@ai...> wrote: > On Mittwoch, 27. Februar 2008, Temlakos wrote: > > Markus: > > > > When you had issued release 1.0.1 of SemanticMediaWiki, the wiki that I > > co-administer was down--someone had compromised our web host's server, > > either with a faulty PHP upgrade or with a trojan; no one knows for > sure. > > > > We have taken one month to get back on-line on a fully dedicated > > server--essentially a "virtual-private-server" physical host with only > > one virtual host, that being ourselves. > > > > And when I reinstalled our wiki and then installed SMW 1.0.1, not a > > single page with my custom data type "Historical Date" would load. They > > all would hang. (Pages not having this data type would not hang.) > > Oh, that is strange. So far SMW did not include the historical date > anyway, so > I cannot imagine what breaks there -- maybe you need some patch that was > accidentally present in SMW 1.0 before (such as having the historical date > in > the language file)? The changes to SMW 1.0.1 were really minor, and it is > certainly safe to copy language files from SMW1.0 if this helps. > > > > > You will no doubt anticipate me and say that the Historical Date type > > was to blame. I might go along with that, except for one thing: the > > Historical Date datatype works without a problem in SMW 1.0, the version > > one step back. But when I try to include it with SMW 1.0.1, I get a > > problem. > > Strange, then maybe you can (partially) downgrade to 1.0. My plans are > still > to make Historical Date the new Date, which is why the datatype is not > included yet. I will rather move its extended features over to Date as > soon > as I get down to it. > > > > > I invite you all to visit our wiki. Actually, this one salient feature > > appears to be the cause of a bad interaction with SMW 1.0.1: namely that > > we store most of our images, not on the wiki itself, but on a separate > > wiki, called the Media Pool. > > It seems even stranger that this should be the problem, since it seems to > be > so unrelated to one particular datatype. > > > The reason for this is that we have content > > in English and in seven additional languages--and serving up eight > > identical copies of an image would produce an upgrader's nightmare and > > might also take up extra hard-disk space that we could put to better > use. > > > > Here is the text of a file named "GlobalSettings.php" that we include > > > > with all the wikis that use this Media Pool: > > > <?php > > > # Shared Image POOL > > > $wgSharedDB = "pool"; > > > > > > $wgUploadNavigationUrl = 'http://creationwiki.org/pool/Special:Upload > '; > > > $wgUseSharedUploads = true; > > > $wgSharedUploadPath = 'http://creationwiki.org/pool/images'; > > > $wgSharedUploadDirectory = > > > '/var/www/vhosts/creationwiki.org/httpdocs/pool/images'; > > > $wgHashedSharedUploadDirectory = true; > > > > > > $wgFetchCommonsDescriptions = true; > > > $wgSharedUploadDBname = 'jcreatio_pool'; # DB-Name of PoolWiki > > > $wgSharedUploadDBprefix = ''; # Table name prefix for PoolWiki > > > $wgRepositoryBaseUrl = "http://creationwiki.org/pool/image.php/Image: > "; > > > > > > ?> > > > > You can see the variables that we set, and the sort of directories we > > set with them. > > > > The trouble seems to arise when we set an absolute directory path for > > the variable: > > > > $wgSharedUploadDirectory > > > > This is a fairly common technique, and we have used it successfully for > > years. That it should break now is something of a puzzle. > > Just as unclear for me, especially since SMW clearly separates its globals > with "smwg" as a prefix, so there should be no accidental name clashes or > the > like. > > > > > If we can't figure out why SMW 1.0.1 breaks when I introduce a custom > > nonlinear data type, then we might not be able to do any more upgrades > > beyond 1.0. > > As I said: SMW1.0 and 1.0.1 are largely compatible. Many files are just > not > changed, and the others can probably be exchanged one-by-one to track down > the issue. Seeing your earlier contributions, I trust your technical > skills > for doing that :-) > > Markus > > > -- > Markus Krötzsch > Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- Sergey Chernyshev http://www.sergeychernyshev.com/ |
From: Temlakos <tem...@gm...> - 2008-02-28 00:12:24
|
Sergey: I doubt that anything would show up in the logs. Nothing happens except that the page fails to load and displays a blank white screen. Every page /not/ having an annotated historical date /does/ load--including pages having other semantic annotations of types other than historical dates. I have the setup mocked-up on my personal machine. That will allow me to institute a testing program without causing annoyance to my fellow site users and administrators. Terry Sergey Chernyshev wrote: > Are there any problems reported in error log? Try to enable debug info > and so on - I would guess that it's some PHP limit that you didn't > re-enable in the new setup. Apache logs should tell you more. > > Sergey > > > On Wed, Feb 27, 2008 at 1:36 PM, Markus Krötzsch > <ma...@ai... <mailto:ma...@ai...>> wrote: > > On Mittwoch, 27. Februar 2008, Temlakos wrote: > > Markus: > > > > When you had issued release 1.0.1 of SemanticMediaWiki, the wiki > that I > > co-administer was down--someone had compromised our web host's > server, > > either with a faulty PHP upgrade or with a trojan; no one knows > for sure. > > > > We have taken one month to get back on-line on a fully dedicated > > server--essentially a "virtual-private-server" physical host > with only > > one virtual host, that being ourselves. > > > > And when I reinstalled our wiki and then installed SMW 1.0.1, not a > > single page with my custom data type "Historical Date" would > load. They > > all would hang. (Pages not having this data type would not hang.) > > Oh, that is strange. So far SMW did not include the historical > date anyway, so > I cannot imagine what breaks there -- maybe you need some patch > that was > accidentally present in SMW 1.0 before (such as having the > historical date in > the language file)? The changes to SMW 1.0.1 were really minor, > and it is > certainly safe to copy language files from SMW1.0 if this helps. > > > > > You will no doubt anticipate me and say that the Historical Date > type > > was to blame. I might go along with that, except for one thing: the > > Historical Date datatype works without a problem in SMW 1.0, the > version > > one step back. But when I try to include it with SMW 1.0.1, I get a > > problem. > > Strange, then maybe you can (partially) downgrade to 1.0. My plans > are still > to make Historical Date the new Date, which is why the datatype is not > included yet. I will rather move its extended features over to > Date as soon > as I get down to it. > > > > > I invite you all to visit our wiki. Actually, this one salient > feature > > appears to be the cause of a bad interaction with SMW 1.0.1: > namely that > > we store most of our images, not on the wiki itself, but on a > separate > > wiki, called the Media Pool. > > It seems even stranger that this should be the problem, since it > seems to be > so unrelated to one particular datatype. > > > The reason for this is that we have content > > in English and in seven additional languages--and serving up eight > > identical copies of an image would produce an upgrader's > nightmare and > > might also take up extra hard-disk space that we could put to > better use. > > > > Here is the text of a file named "GlobalSettings.php" that we > include > > > > with all the wikis that use this Media Pool: > > > <?php > > > # Shared Image POOL > > > $wgSharedDB = "pool"; > > > > > > $wgUploadNavigationUrl = > 'http://creationwiki.org/pool/Special:Upload'; > > > $wgUseSharedUploads = true; > > > $wgSharedUploadPath = 'http://creationwiki.org/pool/images'; > > > $wgSharedUploadDirectory = > > > '/var/www/vhosts/creationwiki.org/httpdocs/pool/images'; > > > $wgHashedSharedUploadDirectory = true; > > > > > > $wgFetchCommonsDescriptions = true; > > > $wgSharedUploadDBname = 'jcreatio_pool'; # DB-Name of PoolWiki > > > $wgSharedUploadDBprefix = ''; # Table name prefix for PoolWiki > > > $wgRepositoryBaseUrl = > "http://creationwiki.org/pool/image.php/Image:"; > > > > > > ?> > > > > You can see the variables that we set, and the sort of > directories we > > set with them. > > > > The trouble seems to arise when we set an absolute directory > path for > > the variable: > > > > $wgSharedUploadDirectory > > > > This is a fairly common technique, and we have used it > successfully for > > years. That it should break now is something of a puzzle. > > Just as unclear for me, especially since SMW clearly separates its > globals > with "smwg" as a prefix, so there should be no accidental name > clashes or the > like. > > > > > If we can't figure out why SMW 1.0.1 breaks when I introduce a > custom > > nonlinear data type, then we might not be able to do any more > upgrades > > beyond 1.0. > > As I said: SMW1.0 and 1.0.1 are largely compatible. Many files are > just not > changed, and the others can probably be exchanged one-by-one to > track down > the issue. Seeing your earlier contributions, I trust your > technical skills > for doing that :-) > > Markus > > > -- > Markus Krötzsch > Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... <mailto:ma...@ai...> > www http://korrekt.org > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > <mailto:Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > -- > Sergey Chernyshev > http://www.sergeychernyshev.com/ > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Sergey C. <sem...@an...> - 2008-02-28 02:54:16
|
I page freezes, it means it's either not delivered by web server which will put something into log file if it happens (you might need to enable debugging data and stuff in MW) or it's delivered to the browser, but it fails to display it. Can you check if there is any page source loaded or better get LiveHTTPHeaders for Firefox / Fiddler for IE and see what got actually delivered from the server? Debugging is the only way to interpret the magic of page not loading and it's pretty hard for us to do it for you, but we can help once we know what you get from logs. Sergey On Wed, Feb 27, 2008 at 7:12 PM, Temlakos <tem...@gm...> wrote: > Sergey: > > I doubt that anything would show up in the logs. Nothing happens except > that the page fails to load and displays a blank white screen. Every > page /not/ having an annotated historical date /does/ load--including > pages having other semantic annotations of types other than historical > dates. > > I have the setup mocked-up on my personal machine. That will allow me to > institute a testing program without causing annoyance to my fellow site > users and administrators. > > Terry > > Sergey Chernyshev wrote: > > Are there any problems reported in error log? Try to enable debug info > > and so on - I would guess that it's some PHP limit that you didn't > > re-enable in the new setup. Apache logs should tell you more. > > > > Sergey > > > > > > On Wed, Feb 27, 2008 at 1:36 PM, Markus Krötzsch > > <ma...@ai... <mailto:ma...@ai...>> wrote: > > > > On Mittwoch, 27. Februar 2008, Temlakos wrote: > > > Markus: > > > > > > When you had issued release 1.0.1 of SemanticMediaWiki, the wiki > > that I > > > co-administer was down--someone had compromised our web host's > > server, > > > either with a faulty PHP upgrade or with a trojan; no one knows > > for sure. > > > > > > We have taken one month to get back on-line on a fully dedicated > > > server--essentially a "virtual-private-server" physical host > > with only > > > one virtual host, that being ourselves. > > > > > > And when I reinstalled our wiki and then installed SMW 1.0.1, not > a > > > single page with my custom data type "Historical Date" would > > load. They > > > all would hang. (Pages not having this data type would not hang.) > > > > Oh, that is strange. So far SMW did not include the historical > > date anyway, so > > I cannot imagine what breaks there -- maybe you need some patch > > that was > > accidentally present in SMW 1.0 before (such as having the > > historical date in > > the language file)? The changes to SMW 1.0.1 were really minor, > > and it is > > certainly safe to copy language files from SMW1.0 if this helps. > > > > > > > > You will no doubt anticipate me and say that the Historical Date > > type > > > was to blame. I might go along with that, except for one thing: > the > > > Historical Date datatype works without a problem in SMW 1.0, the > > version > > > one step back. But when I try to include it with SMW 1.0.1, I get > a > > > problem. > > > > Strange, then maybe you can (partially) downgrade to 1.0. My plans > > are still > > to make Historical Date the new Date, which is why the datatype is > not > > included yet. I will rather move its extended features over to > > Date as soon > > as I get down to it. > > > > > > > > I invite you all to visit our wiki. Actually, this one salient > > feature > > > appears to be the cause of a bad interaction with SMW 1.0.1: > > namely that > > > we store most of our images, not on the wiki itself, but on a > > separate > > > wiki, called the Media Pool. > > > > It seems even stranger that this should be the problem, since it > > seems to be > > so unrelated to one particular datatype. > > > > > The reason for this is that we have content > > > in English and in seven additional languages--and serving up eight > > > identical copies of an image would produce an upgrader's > > nightmare and > > > might also take up extra hard-disk space that we could put to > > better use. > > > > > > Here is the text of a file named "GlobalSettings.php" that we > > include > > > > > > with all the wikis that use this Media Pool: > > > > <?php > > > > # Shared Image POOL > > > > $wgSharedDB = "pool"; > > > > > > > > $wgUploadNavigationUrl = > > 'http://creationwiki.org/pool/Special:Upload'; > > > > $wgUseSharedUploads = true; > > > > $wgSharedUploadPath = 'http://creationwiki.org/pool/images'; > > > > $wgSharedUploadDirectory = > > > > '/var/www/vhosts/creationwiki.org/httpdocs/pool/images'; > > > > $wgHashedSharedUploadDirectory = true; > > > > > > > > $wgFetchCommonsDescriptions = true; > > > > $wgSharedUploadDBname = 'jcreatio_pool'; # DB-Name of PoolWiki > > > > $wgSharedUploadDBprefix = ''; # Table name prefix for PoolWiki > > > > $wgRepositoryBaseUrl = > > "http://creationwiki.org/pool/image.php/Image:"; > > > > > > > > ?> > > > > > > You can see the variables that we set, and the sort of > > directories we > > > set with them. > > > > > > The trouble seems to arise when we set an absolute directory > > path for > > > the variable: > > > > > > $wgSharedUploadDirectory > > > > > > This is a fairly common technique, and we have used it > > successfully for > > > years. That it should break now is something of a puzzle. > > > > Just as unclear for me, especially since SMW clearly separates its > > globals > > with "smwg" as a prefix, so there should be no accidental name > > clashes or the > > like. > > > > > > > > If we can't figure out why SMW 1.0.1 breaks when I introduce a > > custom > > > nonlinear data type, then we might not be able to do any more > > upgrades > > > beyond 1.0. > > > > As I said: SMW1.0 and 1.0.1 are largely compatible. Many files are > > just not > > changed, and the others can probably be exchanged one-by-one to > > track down > > the issue. Seeing your earlier contributions, I trust your > > technical skills > > for doing that :-) > > > > Markus > > > > > > -- > > Markus Krötzsch > > Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > ma...@ai... <mailto:ma...@ai...> > > www http://korrekt.org > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > <mailto:Sem...@li...> > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > > > > > -- > > Sergey Chernyshev > > http://www.sergeychernyshev.com/ > > ------------------------------------------------------------------------ > > > |