Omeka 1.0 Stable Site Corruption

[kevin.reiss]

Hi,

I've been successfully using Omeka 1.0 Stable hosted by bluehost.com
for two sites (one production, another for testing) for approximately
a month. All of a sudden both sites have become corrupted, producing
garbled pages (see http://nycdigital.org/dmetro/) and errors on the
logs such as:

[Tue Jul 14 21:53:00 2009] [notice] mod_fcgid: process /usr/local/
cpanel/cgi-sys/default.fcgi(9322) exit(idle timeout), get stop signal
15 [Tue Jul 14 21:53:09 2009] [error] [client 87.118.118.116] PHP
Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/
php/extensions/no-debug-non-zts-20060613/pdo.so' - /usr/local/lib/php/
extensions/no-debug-non-zts-20060613/pdo.so: undefined symbol:
compiler_globals in Unknown on line 0, referer:
http://acta.lemming-brothers.com/tiki-index.php

The odd thing is that both existing versions of the site, as well as a
fresh installation on the same domain and older .9 version of Omeka I
restored all produce the same errors. I noticed that bluehost has some
history with .htaccess and php.ini file problems but they are a quite
long ago, see http://omeka.org/forums/topic/bluehost-hosting-and-issues-with-pdo_mysql-htaccess-and-phpini.
I noticed that my .htaccess files have trouble with displaying in
bluehost's web based file manager, so I wonder what is happening here.

Anyone else have recent problems with bluehost or found themselves in
a situation where Omeka served up garbled pages?

Thanks for any help,

Kevin Reiss
kevin...@gmail.com

[Dave Lester]

Hi Kevin,

I think your problems relate to two tickets currently on Omeka trac:
https://omeka.org/trac/ticket/796, and https://omeka.org/trac/ticket/797.
Data is being compressed by Omeka, but the proper headers aren't being
sent to the browser.

If that's the problem, then it's just having trouble displaying your
data.. it isn't corrupt. We hope to fix the bugs in the next version
of Omeka (1.1), but I'll look into a possible work-around in the
meantime.

Thanks for letting us know.

Dave

On Jul 15, 12:39 am, "kevin.reiss" <kevin.re...@gmail.com> wrote:
> Hi,
>
> I've been successfully using Omeka 1.0 Stable hosted by bluehost.com
> for two sites (one production, another for testing) for approximately
> a month. All of a sudden both sites have become corrupted, producing

> garbled pages (seehttp://nycdigital.org/dmetro/) and errors on the

> logs such as:
>
> [Tue Jul 14 21:53:00 2009] [notice] mod_fcgid: process /usr/local/
> cpanel/cgi-sys/default.fcgi(9322) exit(idle timeout), get stop signal
> 15 [Tue Jul 14 21:53:09 2009] [error] [client 87.118.118.116] PHP
> Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/
> php/extensions/no-debug-non-zts-20060613/pdo.so' - /usr/local/lib/php/
> extensions/no-debug-non-zts-20060613/pdo.so: undefined symbol:
> compiler_globals in Unknown on line 0, referer:http://acta.lemming-brothers.com/tiki-index.php
>
> The odd thing is that both existing versions of the site, as well as a
> fresh installation on the same domain and older .9 version of Omeka I
> restored all produce the same errors. I noticed that bluehost has some
> history with .htaccess and php.ini file problems but they are a quite

> long ago, seehttp://omeka.org/forums/topic/bluehost-hosting-and-issues-with-pdo_my....

> I noticed that my .htaccess files have trouble with displaying in
> bluehost's web based file manager, so I wonder what is happening here.
>
> Anyone else have recent problems with bluehost or found themselves in
> a situation where Omeka served up garbled pages?
>
> Thanks for any help,
>
> Kevin Reiss

> kevin.re...@gmail.com

[Brian Broadus]

I am having the exact same problem at Bluehost. They explained it as a
server-side problem based around a recompile of Apache, PHP, and
OpenSSL. Then I got this email:

"Secondly, after extensive troubleshooting with several techs and
playing with similar sites and similar issues to nail down a few
issues. First of all, the update we did to php seems to have broken
pdo, which I have done. Now php no longer segfaults on page load, but
it still dumps that garbage to the screen.

Tracing the execution of this problem shows the program looking for
several files and directories that doesn't exist, including /Omeka, /
include/Omeka, and a few others. At this time, the best course of
action is to consult a programmer. Let us know if there's anything
else we can assist with."

My site is a real labor of love and very, very important to me.
(www.keepingcairo.org).It's got hundreds of hours in it. I don't think
that it's corrupt, it's just not displaying properly. I really need a
work-around. I'm running 1.0beta. It was doing great until the
recompile work at Bluehost. I couldn't have been happier with the way
it was coming together. I'm not a programmer, I'm an amateur who can
hack some code.

brian....@broadusllc.com

[kevin.reiss]

Hi Dave,

Thanks for the heads up on those bugs. The error log definitely has
500 code premature script headers entries as well, however I'm puzzled
as to why I was able to run the exact same code on a different
bluehost account that I have access to. Both of my bluehost accounts
run exactly the same php environment are using a similar php.ini. If
you have any workaround suggestions that would be most appreciated.

On Jul 15, 12:48 am, Dave Lester <daveles...@gmail.com> wrote:
> Hi Kevin,
>

> I think your problems relate to two tickets currently on Omeka trac:https://omeka.org/trac/ticket/796, andhttps://omeka.org/trac/ticket/797.

[Brian Broadus]

I am definitely getting the following as well. Dave Lester, this is
supposed to have begun when Bluehost compiled Apache and did a PHP
update on Monday. My site went from operating perfectly to looking
like yours does in matter of an hour or less. Bluehost said that a ton
of sites had one of basically three kinds of problems. Initially it
seemed like a conflict between an optimizer and the PHP. Until I got
my email above at about 10:00pm last night, Bluehost was sure it was
their own fault. I'm very suspicious that it is indeed Bluehost's
fault, given that it went from working to not working after Bluehost
did something, not me.

[Wed Jul 15 09:27:17 2009] [warn] Cannot get media subtype. [Wed Jul
15 09:27:18 2009] [error] [client 66.249.68.181] Premature end of
script headers: archive.php [Wed Jul 15 09:27:18 2009] [error] [client
66.249.68.181] Premature end of script headers: 500.php

[Dave Lester]

Like I said in the earlier message, I believe the problem is with
displaying your data.. not the data itself. Can you try commenting
out lines 26-30 of paths.php (the if(extension_loaded('zlib')) clause)
to fix the garbled output? This is a temporary fix until the next
release (Omeka 1.1). Let me know if that works.

Dave

[Brian Broadus]

// Set the zlib config values if the extension has been loaded.
//if (extension_loaded('zlib')) {
// ini_set('zlib.output_compression', 'On');
// ini_set('zlib.output_compression_level', '5');
//}

This is what the paths.php file looks like now. But the site
( www.keepingcairo.org ) is just a blank page. So is the Admin
dashboard. The garbage is gone, but so is everything else.

[Patrick Murray-John]

Hi all,

I've got same or similar issues on BH both with omeka and with drupal,
which seems to point to a BH screwup? I'm attacking this from the BH
end since it is affecting my drupal installation as well. Will share
anything I can pry out of them.

Patrick

[w.grot...@gmail.com]

When I telnet to your site, I get this back. Don't know if it helps
with your diagnosis or not but thought I'd toss it into the
discussion. - Wally


telnet www.keepingcairo.org 80
Trying 66.147.242.173...
Connected to keepingcairo.org.
Escape character is '^]'.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>GET to /default.shtml not supported.<br />
</p>
<p>Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle
the request.</p>
<hr>
<address>Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8k DAV/2
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server
at box573.bluehost.com Port 80</address>
</body></html>
Connection closed by foreign host.
deskbox:~ wallyg$

On Jul 15, 12:46 pm, Patrick Murray-John <pgose...@umw.edu> wrote:
> Hi all,
>
> I've got same or similar issues on BH both with omeka and with drupal,
> which seems to point to a BH screwup?  I'm attacking this from the BH
> end since it is affecting my drupal installation as well.  Will share
> anything I can pry out of them.
>
> Patrick
>
>
>
> Brian Broadus wrote:
> > // Set the zlib config values if the extension has been loaded.
> > //if (extension_loaded('zlib')) {
> > //  ini_set('zlib.output_compression', 'On');
> > //  ini_set('zlib.output_compression_level', '5');
> > //}
>
> > This is what the paths.php file looks like now. But the site

> > (www.keepingcairo.org) is just a blank page. So is the Admin

[Brian Broadus]

Good man, Patrick. As I said above, until last night at 10:00pm,
everyone at BH was positive it was a BH problem. Nothing changed on my
site, nothing. And then the bottom fell out. They were thinking it was
a conflict between Zend and Apache and said that they were working
with Zend to fix the problem.

On Jul 15, 12:46 pm, Patrick Murray-John <pgose...@umw.edu> wrote:

> Hi all,
>
> I've got same or similar issues on BH both with omeka and with drupal,
> which seems to point to a BH screwup?  I'm attacking this from the BH
> end since it is affecting my drupal installation as well.  Will share
> anything I can pry out of them.
>
> Patrick
>
> Brian Broadus wrote:
> > // Set the zlib config values if the extension has been loaded.
> > //if (extension_loaded('zlib')) {
> > //  ini_set('zlib.output_compression', 'On');
> > //  ini_set('zlib.output_compression_level', '5');
> > //}
>
> > This is what the paths.php file looks like now. But the site

> > (www.keepingcairo.org) is just a blank page. So is the Admin

[Brian Broadus]

Thanks, Wally. I'm not really a programmer, so I don't know what this
means. Can you or anyone else tell me if it's a Bluehost server issue?
from what you telnetted?

On Jul 15, 12:56 pm, "w.grotopho...@gmail.com"

[w.grot...@gmail.com]

Just a guess but all I read on the web about this problem and php
seems to indicate that Apache's mod_security module is at fault. Hard
to diagnose whether that's relevant in this case without access to
what bluehost sees in their logs.

http://bit.ly/SYQW6

that link talks about the problem in the context of
WordPress...similar on some levels to Omeka.


Anyway, I'm probably just clouding up the waters so I'll stay out of
this discussion until I find something concrete.

- Wally

[Brian Broadus]

I got off the phone with BH. BH's script readers don't know Omeka, but
they are sure that they see something wrong with the PHP. They think
that this is not a BH problem. At this stage, I've taken Dave Lester's
advice and that's not really done anything for me (thanks for trying,
though) so I'm at a loss.

On Jul 15, 1:23 pm, "w.grotopho...@gmail.com"

[Patrick Murray-John]

Hi all,

Yep---the word I just got from BH is this is a known issue they're working on. Here's what they sent me:

Yes we have made some updates to both Apache and PHP. Unfortunately there are some issues with incompatibility with older php.ini files and the new version of PHP5. Installing a new php.ini file while fix the issue with your blog. The other page that has garbage at the top is using the Zend optimizer to render the page. Apparently the new PHP5 has issue with the Zend optimizer. We have admins working with the developers of Zend to get this issue resolved as soon as possible. We have no ETA on when it will be resolved though.

Not ideal, but hopefully it means we don't have to try to chase it down.

Patrick

>>> Brian Broadus <brian....@gmail.com> 07/15/09 1:08 PM >>>

[Patrick Murray-John]

Brian,

Heh-heh. This wouldn't be the first time that I got conflicting statements from BH.

Patrick

>>> Brian Broadus <brian....@gmail.com> 07/15/09 2:10 PM >>>

I got off the phone with BH. BH's script readers don't know Omeka, but
they are sure that they see something wrong with the PHP. They think
that this is not a BH problem. At this stage, I've taken Dave Lester's
advice and that's not really done anything for me (thanks for trying,
though) so I'm at a loss.

On Jul 15, 1:23 pm, "w.grotopho...@gmail.com"
<w.grotopho...@gmail.com> wrote:
> Just a guess but all I read on the web about this problem and php
> seems to indicate that Apache's mod_security module is at fault. Hard
> to diagnose whether that's relevant in this case without access to
> what bluehost sees in their logs.
>
> http://bit.ly/SYQW6
>
> that link talks about the problem in the context of
> WordPress...similar on some levels to Omeka.
>
> Anyway, I'm probably just clouding up the waters so I'll stay out of
> this discussion until I find something concrete.
>
> - Wally
>
> On Jul 15, 1:07 pm, Brian Broadus <brian.broa...@gmail.com> wrote:
>

[Brian Broadus]

Well, the BH server is down now. I hope that's actually good news. I
thought that the MySQL was shown as failed on the MycPanel and I
wanted to call that to the tech's attention. Server is supposed to be
up soon. What's your plan, Patrick? I hope that Omeka is talking to
Bluehost about this right now. BH told me to hire a programmer to fix
the PHP (see above) which I could do, except that I'm not that the
code is the problem, especially since Dave Lester thought he'd given
us a workaround. So, BH told you that the problem was with the Zend
optimizer? That was the story yesterday before I got my "bad PHP"
email. And, the Zend story is directed at the Omeka site? Is that
right?

On Jul 15, 2:15 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:
> Brian,
>
> Heh-heh.  This wouldn't be the first time that I got conflicting statements from BH.  
>
> Patrick
>

> >>> Brian Broadus <brian.broa...@gmail.com> 07/15/09 2:10 PM >>>

[Patrick Murray-John]

Brian,

Interesting... I saw the same mysql failed message. That might be worth us letting them know about. I wonder if it is related to the Zend optimizer issue (if there is one!).

The 'bad PHP' email might be a less savvy version of the Zend optimizer statement. Since Omeka runs on Zend, a detailed, precise understanding of the issue might recognize that the issue is with Zend. A really sloppy epic fail understanding of the issue might say simply "Oh, there's something wrong with the PHP" and not parse out the distinction between whether the issue is with Zend itself or with the app built on top of Zend. That sloppy understanding would then tell you to find a programmer, not realizing that ultimately that would mean changing Zend.

Since we have documented that the same issue arose across many Omeka installations running on BH, right at the same time, I'd say that's pretty strong evidence that the issue is BH's -- ahem -- upgrade, and the idea that it's somewhere in an incompatibility between Zend and the new PHP5 seems most plausible. However, that also seems really odd that Zend and any version of PHP5 wouldn't play nicely. I'd like to know if other Zend-based apps are having troubles. Is there a Zend "Hello World" to slap up and test? I'll see if I can find one, or if anyone can direct me to one, I'll try that out to see what happens.

Maybe a next step might be to direct BH's tech guys to this thread? I'm a big hesitant to do so unless the Omeka folks are happy with that. But I think it would be effective 1) to give them additional info 2) to demonstrate the evidence that this is a problem related to their upgrade, not the Omeka code and 3) to demonstrate that they are causing serious disruption to many sites that have a lot of time and love devoted to them, which isn't so good for business. (Yeah, I'm talkin' to you, BlueHost)

Patrick

>>> Brian Broadus <brian....@gmail.com> 07/15/09 2:33 PM >>>

[Brian Broadus]

Yes. I didn't understand how Zend and Apache wouldn't work together.
That was my first reaction. I hope that Omeka (Dave Lester?) is
working with Bluehost or someone on it. And yes, how is it that one
minute the site worked, the next it didn't, if it wasn't a BH problem.

On Jul 15, 2:48 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:
> Brian,
>

> Interesting... I saw the same mysql failed message.  That might be worth us letting them know about.  I wonder if it is related to the Zend optimizer issue (if there is one!).
>
> The 'bad PHP' email might be a less savvy version of the Zend optimizer statement.  Since Omeka runs on Zend, a detailed, precise understanding of the issue might recognize that the issue is with Zend.  A really sloppy epic fail understanding of the issue might say simply "Oh, there's something wrong with the PHP" and not parse out the distinction between whether the issue is with Zend itself or with the app built on top of Zend.  That sloppy understanding would then tell you to find a programmer, not realizing that ultimately that would mean changing Zend.
>
> Since we have documented that the same issue arose across many Omeka installations running on BH, right at the same time, I'd say that's pretty strong evidence that the issue is BH's -- ahem -- upgrade, and the idea that it's somewhere in an incompatibility between Zend and the new PHP5 seems most plausible.  However, that also seems really odd that Zend and any version of PHP5 wouldn't play nicely.  I'd like to know if other Zend-based apps are having troubles.  Is there a Zend "Hello World" to slap up and test?  I'll see if I can find one, or if anyone can direct me to one, I'll try that out to see what happens.
>
> Maybe a next step might be to direct BH's tech guys to this thread?  I'm a big hesitant to do so unless the Omeka folks are happy with that.  But I think it would be effective 1) to give them additional info 2) to demonstrate the evidence that this is a problem related to their upgrade, not the Omeka code and 3) to demonstrate that they are causing serious disruption to many sites that have a lot of time and love devoted to them, which isn't so good for business. (Yeah, I'm talkin' to you, BlueHost)
>
> Patrick
>

> >>> Brian Broadus <brian.broa...@gmail.com> 07/15/09 2:33 PM >>>

[Jeremy Boggs]

Thanks to everyone on the thread. I think its pretty to everyone who
has a Bluehost account and is using Omeka.

On Jul 15, 2009, at 3:02 PM, Brian Broadus wrote:

> I hope that Omeka (Dave Lester?) is working with Bluehost or someone
> on it.

At this time, it seems this is a problem with Bluehost, over which we
have no control. If we learn more and find out that there are issues
with Omeka, we'll happily address those.

On Jul 15, 2:48 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:

> Maybe a next step might be to direct BH's tech guys to this thread?
> I'm a big hesitant to do so unless the Omeka folks are happy with
> that.

Don't hesitate at all, Patrick! This seems like it might be a great
approach, since this really seems to be a larger issue with Bluehost,
and not something specific to Omeka. If someone at Bluehost is willing
to participate in this thread, that'd be great, and we'd certainly
welcome them.

Thanks again!

Jeremy
Omeka Development Team Manager

[Patrick Murray-John]

Brian,

My best guess so far is that this isn't an Omeka thing, it's a Zend thing. So I'm thinking that the first thing to confirm is whether it really is a Zend thing (That's where a Zend test comes into play). That'll tell us whether it's in the underlying Zend framework or in how Omeka works with Zend, and so tell us whether the Omeka folks need to address something in their code, or just wait for the Zend and BH people to straighten things out.

Patrick

>>> Brian Broadus <brian....@gmail.com> 07/15/09 3:04 PM >>>

Yes. I didn't understand how Zend and Apache wouldn't work together.
That was my first reaction. I hope that Omeka (Dave Lester?) is
working with Bluehost or someone on it. And yes, how is it that one
minute the site worked, the next it didn't, if it wasn't a BH problem.

On Jul 15, 2:48 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:

[Brian Broadus]

Patrick, why don't you take the lead on getting Bluehost's attention
to this thread and Omeka? The Zend test seems to be the trick.
Obviously, we're not running a Zend test for Bluehost. I'm not really
sure what Zend even is. What is your suggestion that I do to get my
site up and running again, Jeremy? I understand that Omeka isn't
responsible, but are you guys calling Bluehost? I've got no love lost
for Bluehost at this point and could switch to another hosting company
and move my domain there. Any recommendations? I just want my site to
work again with minimal hassle. Really, that's the bottom line to me.
Omeka was, all in all, doing a great job for me until Bluehost screwed
with it. I'm not a tech. I want to get on with my life, which is that
of a scholar of architectural history and Egypt. In this little corner
of the academic world, my site was pretty much unique and I was very
happy to keeping it growing. I just want somewhere it will be safe.
Now, I can't even get to the Omeka dashboard on it.

On Jul 15, 3:16 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:
> Brian,
>

> My best guess so far is that this isn't an Omeka thing, it's a Zend thing.  So I'm thinking that the first thing to confirm is whether it really is a Zend thing (That's where a Zend test comes into play).  That'll tell us whether it's in the underlying Zend framework or in how Omeka works with Zend, and so tell us whether the Omeka folks need to address something in their code, or just wait for the Zend and BH people to straighten things out.
>
> Patrick
>

> >>> Brian Broadus <brian.broa...@gmail.com> 07/15/09 3:04 PM >>>

[Patrick Murray-John]

Sounds good! Just replied to the email I got from Scott (the BH person who responded to me) with a link to the thread. Keeping fingers hopefully crossed!

Patrick

>>> Jeremy Boggs <jer...@clioweb.org> 07/15/09 3:18 PM >>>

Thanks to everyone on the thread. I think its pretty to everyone who
has a Bluehost account and is using Omeka.

On Jul 15, 2009, at 3:02 PM, Brian Broadus wrote:

> I hope that Omeka (Dave Lester?) is working with Bluehost or someone
> on it.

At this time, it seems this is a problem with Bluehost, over which we
have no control. If we learn more and find out that there are issues
with Omeka, we'll happily address those.

On Jul 15, 2:48 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:

> Maybe a next step might be to direct BH's tech guys to this thread?
> I'm a big hesitant to do so unless the Omeka folks are happy with
> that.

[Patrick Murray-John]

Brian,

I only have the sketchiest of understandings, but the relationship as I understand it between Zend and Omeka is that Zend provides a whole pile of abstract functionality for anyone to build off of. So for common tasks, it provides a built-in way to put them together more quickly. Kinda like when a sous chef has done all the common food-prep tasks of chopping and slicing and dicing and neatly arranged it all in little bowls for the chef (here, the Omeka team) to cook up into something tasty.

But if the sous chef (Zend) and the knives (Bluehost) don't work well together, the end meal (your Omeka installation) tastes like shit.

How's THAT for an extended analogy?!

Hopefully we'll hear back from BH soon. In my experience with them, the guy I'm in contact with (Scott) has been, from what I can tell from first contact, one of the better ones in terms of quick and clear and honest replies.

Patrick

>>> Brian Broadus <brian....@gmail.com> 07/15/09 3:38 PM >>>

Patrick, why don't you take the lead on getting Bluehost's attention
to this thread and Omeka? The Zend test seems to be the trick.
Obviously, we're not running a Zend test for Bluehost. I'm not really
sure what Zend even is. What is your suggestion that I do to get my
site up and running again, Jeremy? I understand that Omeka isn't
responsible, but are you guys calling Bluehost? I've got no love lost
for Bluehost at this point and could switch to another hosting company
and move my domain there. Any recommendations? I just want my site to
work again with minimal hassle. Really, that's the bottom line to me.
Omeka was, all in all, doing a great job for me until Bluehost screwed
with it. I'm not a tech. I want to get on with my life, which is that
of a scholar of architectural history and Egypt. In this little corner
of the academic world, my site was pretty much unique and I was very
happy to keeping it growing. I just want somewhere it will be safe.
Now, I can't even get to the Omeka dashboard on it.

On Jul 15, 3:16 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:
> Brian,
>
> My best guess so far is that this isn't an Omeka thing, it's a Zend thing. So I'm thinking that the first thing to confirm is whether it really is a Zend thing (That's where a Zend test comes into play). That'll tell us whether it's in the underlying Zend framework or in how Omeka works with Zend, and so tell us whether the Omeka folks need to address something in their code, or just wait for the Zend and BH people to straighten things out.
>
> Patrick
>
> >>> Brian Broadus <brian.broa...@gmail.com> 07/15/09 3:04 PM >>>
>
> Yes. I didn't understand how Zend and Apache wouldn't work together.
> That was my first reaction. I hope that Omeka (Dave Lester?) is
> working with Bluehost or someone on it. And yes, how is it that one
> minute the site worked, the next it didn't, if it wasn't a BH problem.
>

> On Jul 15, 2:48 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:
>

[Brian Broadus]

Jimmy at BH has this thread and says, after working on the problem,
it's definitely Zend. He said it's getting escalated, but that there's
nothing wrong with the PHP of Omeka, at least that they see now. I
asked him to post something to this thread when he knows something. It
has been escalated to the development guys. I told him that it was
important that we be kept informed.

On Jul 15, 3:55 pm, "Patrick Murray-John" <pgose...@umw.edu> wrote:
> Brian,
>

> I only have the sketchiest of understandings, but the relationship as I understand it between Zend and Omeka is that Zend provides a whole pile of abstract functionality for anyone to build off of.  So for common tasks, it provides a built-in way to put them together more quickly.  Kinda like when a sous chef has done all the common food-prep tasks of chopping and slicing and dicing and neatly arranged it all in little bowls for the chef (here, the Omeka team) to cook up into something tasty.
>
> But if the sous chef (Zend) and the knives (Bluehost) don't work well together, the end meal (your Omeka installation) tastes like shit.
>
> How's THAT for an extended analogy?!
>
> Hopefully we'll hear back from BH soon.  In my experience with them, the guy I'm in contact with (Scott) has been, from what I can tell from first contact, one of the better ones in terms of quick and clear and honest replies.
>
> Patrick
>

> >>> Brian Broadus <brian.broa...@gmail.com> 07/15/09 3:38 PM >>>

> ...
>
> read more »

[kevin.reiss]

Hi,

I haven't had time to review all the details here but I did want to
mention one relevant thing I discovered, particularly since Patrick
has escalated this with Bluehost, that I was able to successfully
mount the same exact set of 1.0 production code that isn't functioning
for me at http://nycdigital.org/demtro/ at another bluehost domain I
use at http://cunylibraries.org/dmetro/. I'm using the same basic
global php.ini set-up bluehost provides for PHP5 at both sites too.
Really odd.

Kevin

> ...
>
> read more »

[kevin.reiss]

Sorry that is http://nycdigital.org/dmetro/ not http://nycdigital.org/demtro/.

On Jul 15, 4:57 pm, "kevin.reiss" <kevin.re...@gmail.com> wrote:
> Hi,
>
> I haven't had time to review all the details here but I did want to
> mention one relevant thing I discovered, particularly since Patrick
> has escalated this with Bluehost, that I was able to successfully
> mount the same exact set of 1.0 production code that isn't functioning

> for me athttp://nycdigital.org/demtro/at another bluehost domain I
> use athttp://cunylibraries.org/dmetro/. I'm using the same basic

> ...
>
> read more »

[kevin.reiss]

Hi,

I was able to fix my own problem with the garbled text by Dave's
simple suggestion of commenting out 26-30 of paths.php on both of my
two 1.0 stable sites. Thanks for everyone's helpful comments. I didn't
get a good explanation on my bluehost inquiry as to why the same code
ran well one bluehost domain but failed on another.

Thanks again,

Kevin

On Jul 15, 12:10 pm, Dave Lester <daveles...@gmail.com> wrote:

[Brian Broadus]

I tried Dave's suggestion, but it just gave me blank pages instead of
garbled ones.

[Brian Broadus]

I am running 1.0beta. I can't upgrade right now by following the
instructions on the Omeka website because I can't get to Omeka Admin
dashboard to disable plugins. The dashboard is blank. Would disabling
the plugins really make a difference in doing the upgrade? Can I just
back up the database, install Omeka 1.0stable, and go with the rest of
the upgrade? I thing that the only plug-in I'm using that did not come
with the Omeka package itself is Social Networking. Exhibit Builder
and Simple Pages were the others I remember.

On Jul 15, 11:31 pm, "kevin.reiss" <kevin.re...@gmail.com> wrote:

[Patrick Murray-John]

Here's an additional possible twist. Don't know if it will help anyone
else out or not.

Working from the original message BH sent me, to get a Drupal
installation back up and running I had to reinstall the php.ini file,
which controls a lot of PHP settings. Apparently, the php.ini file that
BH originally put on my server is not compatible with their recent PHP
upgrade. Best guess is that it's a difference between what was good for
PHP4 and for PHP5.

If putting in the new php.ini file (in the cpanel under software /
services click the php config. From there you can install the master
php.ini.default file ) makes things happier, then it might explain why
some sites were good and some were bad: domains that have been around
longer might have the old php.ini file. Domains that were created more
recently might have gotten the correct php.ini.

Just a guess, and I haven't chased through testing it (my domain is a
tangled mess of subdomains and subdirectories , many of which have
their own php.ini files). But thought I'd throw this out in case it helps.

Patrick

[Patrick Murray-John]

Yay!

The combo of commenting out 26-30 in paths.php plus putting the new

php.ini file (in the cpanel under software / services click the php
config. From there you can install the master php.ini.default file )

into the directory where the omeka installation lives worked to save at
least one of my installations.

Patrick

[Patrick Murray-John]

Ooops!

The new php.ini file that BH put in my domain leaves error reporting
going right to the screen. Changing
display_errors: On

to

display_errors:Off

in line 277 will hide errors if you are seeing any.

I'm attaching a copy of BH's new php.ini file in case anyone sees
anything else iffy in it.

Patrick

[Brian Broadus]

I just got these:

Message 01:

I turned this section of code off in the paths.php file:

// Set the zlib config values if the extension has been loaded.

if (extension_loaded('zlib')) {
//ini_set('zlib.output_compression', 'On');
//ini_set('zlib.output_compression_level', '5');
}

the 2 // infront of the ini_set's comments them out. This has stopped
the junk from displaying on the screen. Then in the same file I turned
on error reporting. Now it looks like your site is missing this folder
and file:

Omeka/Core.php


Message 02:


I actually found a bug for the zlib things:

//ini_set('zlib.output_compression', 'On');
//ini_set('zlib.output_compression_level', '5');

needs to be

ini_set('zlib.output_compression', true);

ini_set('zlib.output_compression_level', '5');

> [php.ini.new38K ][PHP]
>
> ;;;;;;;;;;;
> ; WARNING ;
> ;;;;;;;;;;;
> ; This is the default settings file for new PHP installations.
> ; By default, PHP installs itself with a configuration suitable for
> ; development purposes, and *NOT* for production purposes.
> ; For several security-oriented considerations that should be taken
> ; before going online with your site, please consult php.ini-recommended
> ; andhttp://php.net/manual/en/security.php.
>
> ;;;;;;;;;;;;;;;;;;;
> ; About this file ;
> ;;;;;;;;;;;;;;;;;;;
> ; This file controls many aspects of PHP's behavior.  In order for PHP to
> ; read it, it must be named 'php.ini'.  PHP looks for it in the current
> ; working directory, in the path designated by the environment variable
> ; PHPRC, and in the path that was defined in compile time (in that order).
> ; Under Windows, the compile-time path is the Windows directory.  The
> ; path in which the php.ini file is looked for can be overridden using
> ; the -c argument in command line mode.
> ;
> ; The syntax of the file is extremely simple.  Whitespace and Lines
> ; beginning with a semicolon are silently ignored (as you probably guessed).
> ; Section headers (e.g. [Foo]) are also silently ignored, even though
> ; they might mean something in the future.
> ;
> ; Directives are specified using the following syntax:
> ; directive = value
> ; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
> ;
> ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
> ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
> ; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
> ;
> ; Expressions in the INI file are limited to bitwise operators and parentheses:
> ; |        bitwise OR
> ; &        bitwise AND
> ; ~        bitwise NOT
> ; !        boolean NOT
> ;
> ; Boolean flags can be turned on using the values 1, On, True or Yes.
> ; They can be turned off using the values 0, Off, False or No.
> ;
> ; An empty string can be denoted by simply not writing anything after the equal
> ; sign, or by using the None keyword:
> ;
> ;  foo =         ; sets foo to an empty string
> ;  foo = none    ; sets foo to an empty string
> ;  foo = "none"  ; sets foo to the string 'none'
> ;
> ; If you use constants in your value, and these constants belong to a
> ; dynamically loaded extension (either a PHP extension or a Zend extension),
> ; you may only use these constants *after* the line that loads the extension.
> ;
> ; All the values in the php.ini-dist file correspond to the builtin
> ; defaults (that is, if no php.ini is used, or if you delete these lines,
> ; the builtin defaults will be identical).
>
> ;;;;;;;;;;;;;;;;;;;;
> ; Language Options ;
> ;;;;;;;;;;;;;;;;;;;;
>
> ; Enable the PHP scripting language engine under Apache.
> engine = On
>
> ; Allow the <? tag.  Otherwise, only <?php and <script> tags are recognized.  
> ; NOTE: Using short tags should be avoided when developing applications or
> ; libraries that are meant for redistribution, or deployment on PHP
> ; servers which are not under your control, because short tags may not
> ; be supported on the target server. For portable, redistributable code,
> ; be sure not to use short tags.
> short_open_tag = On
>
> ; Allow ASP-style <% %> tags.
> asp_tags = Off
>
> ; The number of significant digits displayed in floating point numbers.
> precision    =  12
>
> ; Enforce year 2000 compliance (will cause problems with non-compliant browsers)
> y2k_compliance = On
>
> ; Output buffering allows you to send header lines (including cookies) even
> ; after you send body content, at the price of slowing PHP's output layer a
> ; bit.  You can enable output buffering during runtime by calling the output
> ; buffering functions.  You can also enable output buffering for all files by
> ; setting this directive to On.  If you wish to limit the size of the buffer
> ; to a certain size - you can use a maximum number of bytes instead of 'On', as
> ; a value for this directive (e.g., output_buffering=4096).
> output_buffering = Off
>
> ; You can redirect all of the output of your scripts to a function.  For
> ; example, if you set output_handler to "mb_output_handler", character
> ; encoding will be transparently converted to the specified encoding.
> ; Setting any output handler automatically turns on output buffering.
> ; Note: People who wrote portable scripts should not depend on this ini
> ;       directive. Instead, explicitly set the output handler using ob_start().
> ;       Using this ini directive may cause problems unless you know what script
> ;       is doing.
> ; Note: You cannot use both "mb_output_handler" with "ob_iconv_handler"
> ;       and you cannot use both "ob_gzhandler" and "zlib.output_compression".
> ;output_handler =
>
> ; Transparent output compression using the zlib library
> ; Valid values for this option are 'off', 'on', or a specific buffer size
> ; to be used for compression (default is 4KB)
> ; Note: Resulting chunk size may vary due to nature of compression. PHP
> ;       outputs chunks that are few hundreds bytes each as a result of
> ;       compression. If you prefer a larger chunk size for better
> ;       performance, enable output_buffering in addition.
> ; Note: You need to use zlib.output_handler instead of the standard
> ;       output_handler, or otherwise the output will be corrupted.
> zlib.output_compression = Off
>
> ; You cannot specify additional output handlers if zlib.output_compression
> ; is activated here. This setting does the same as output_handler but in
> ; a different order.
> ;zlib.output_handler =
>
> ; Implicit flush tells PHP to tell the output layer to flush itself
> ; automatically after every output block.  This is equivalent to calling the
> ; PHP function flush() after each and every call to print() or echo() and each
> ; and every HTML block.  Turning this option on has serious performance
> ; implications and is generally recommended for debugging purposes only.
> implicit_flush = Off
>
> ; The unserialize callback function will be called (with the undefined class'
> ; name as parameter), if the unserializer finds an undefined class
> ; which should be instanciated.
> ; A warning appears if the specified function is not defined, or if the
> ; function doesn't include/implement the missing class.
> ; So only set this entry, if you really want to implement such a
> ; callback-function.
> unserialize_callback_func=
>
> ; When floats & doubles are serialized store serialize_precision significant
> ; digits after the floating point. The default value ensures that when floats
> ; are decoded with unserialize, the data will remain the same.
> serialize_precision = 100
>
> ; Whether to enable the ability to force arguments to be passed by reference
> ; at function call time.  This method is deprecated and is likely to be
> ; unsupported in future versions of PHP/Zend.  The encouraged method of
> ; specifying which arguments should be passed by reference is in the function
> ; declaration.  You're encouraged to try and turn this option Off and make
> ; sure your scripts work properly with it in order to ensure they will work
> ; with future versions of the language (you will receive a warning each time
> ; you use this feature, and the argument will be passed by value instead of by
> ; reference).
> allow_call_time_pass_reference = On
>
> ; Safe Mode
> ;
> safe_mode = Off
>
> ; By default, Safe Mode does a UID compare check when
> ; opening files. If you want to relax this to a GID compare,
> ; then turn on safe_mode_gid.
> safe_mode_gid = Off
>
> ; When safe_mode is on, UID/GID checks are bypassed when
> ; including files from this directory and its subdirectories.
> ; (directory must also be in include_path or full path must
> ; be used when including)
> safe_mode_include_dir =                                                        
>
> ; When safe_mode is on, only executables located in the safe_mode_exec_dir
> ; will be allowed to be executed via the exec family of functions.
> safe_mode_exec_dir =
>
> ; Setting certain environment variables may be a potential security breach.
> ; This directive contains a comma-delimited list of prefixes.  In Safe Mode,
> ; the user may only alter environment variables whose names begin with the
> ; prefixes supplied here.  By default, users will only be able to set
> ; environment variables that begin with PHP_ (e.g. PHP_FOO=BAR).
> ;
> ; Note:  If this directive is empty, PHP will let the user modify ANY
> ; environment variable!
> safe_mode_allowed_env_vars = PHP_
>
> ; This directive contains a comma-delimited list of environment variables that
> ; the end user won't be able to change using putenv().  These variables will be
> ; protected even if safe_mode_allowed_env_vars is set to allow to change them.
> safe_mode_protected_env_vars = LD_LIBRARY_PATH
>
> ; open_basedir, if set, limits all file operations to the defined directory
> ; and below.  This directive makes most sense if used in a per-directory
> ; or per-virtualhost web server configuration file. This directive is
> ; *NOT* affected by whether Safe Mode is turned On or Off.
> ;open_basedir =
>
> ; This directive allows you to disable certain functions for security reasons.
> ; It receives a comma-delimited list of function names. This directive is
> ; *NOT* affected by whether Safe Mode is turned On or Off.
> disable_functions =
>
> ; This directive allows you to disable certain classes for security reasons.
> ; It receives a comma-delimited list of class names. This directive is
> ; *NOT* affected by whether Safe Mode is turned On or Off.
> disable_classes =
>
> ; Colors for Syntax Highlighting mode.  Anything that's acceptable in
> ; <font color="??????"> would work.
> ;highlight.string  = #DD0000
> ;highlight.comment = #FF9900
> ;highlight.keyword = #007700
> ;highlight.bg      = #FFFFFF
> ;highlight.default = #0000BB
> ;highlight.html    = #000000
>
> ;
> ; Misc
> ;
> ; Decides whether PHP may expose the fact that it is installed on the server
> ; (e.g. by adding its signature to the Web server header).  It is no security
> ; threat in any way, but it makes it possible to determine whether you use PHP
> ; on your server or not.
> expose_php = On
>
> ;;;;;;;;;;;;;;;;;;;
> ; Resource Limits ;
> ;;;;;;;;;;;;;;;;;;;
>
> max_execution_time = 30     ; Maximum execution time of each script, in seconds
> max_input_time ...
>
> read more »

[Brian Broadus]

The new PHP.INI did nothing for me. When I turn off error reporting, I
get a blank screen. When it's on, I get:

Warning: require_once(Omeka/Core.php) [function.require-once]: failed
to open stream: No such file or directory in /home6/keepinh1/
public_html/index.php on line 18

Fatal error: require_once() [function.require]: Failed opening
required 'Omeka/Core.php' (include_path='/home6/keepinh1/public_html/
application/libraries:/home6/keepinh1/public_html/application/models')
in /home6/keepinh1/public_html/index.php on line 18




Help!

> ...
>
> read more »

[Brian Broadus]

Problems solved.

Basically, the tech at Bluehost reinstalled Omeka and he and I did an
upgrade to 1.0 stable, plus the debugged paths.php that the script guy
at Bluehost identified regarding the zlib stuff (two messages up). The
front end of the site immediately looked great. The back end sucked.
Lots of script errors in the Dashboard and no prompt to upgrade to 1.0
as in step 7 upgrade instructions. The dashboard still thinks I am on
1.0beta, but the site is actually 1.0. It was all usable stuff, just a
mess. So, I had the flash of insight and just disabled error reporting
in the paths.php and it's just like the old days. Except, yes, I
wouldn't mind upgrading the back end just for the neatness of it, but
I can live with the constant reminder to upgrade even though, yes, I
have already upgraded. Maybe I will wait for a later version.

[Brian Broadus]

I got a message from the techs at Bluehost who said that, with regards
to Zend:

"This was one of the problems that we were seeing with the new update
of php. Due to this and other problems we have rolled back to php
5.2.9 so this should fix the problem."