Weird problem on host, not on local setup

Okay.

I have a setup-script (home made) which also sets up quite a bit of database tables and populates some of the tables. All of this works just fine when I run it on my local server, but when I upload the files to a demo-site, and try running it there, it fails, with an empty error-message - which I find weird, since looking at it, it should always return SOMETHING in the error-message.

The script leaves a bit of garbage in the php-error.log, but nothing major - notices mostly, some undeclared variables etc. Nothing pertaining to the specific page of the script that is breaking, however.

It's all run via ajax-calls, via jQuery (yes, yes, I know, I know), and as I said, it works fine on my local server - not as much on the remote one. I can post the code here, but it's long (about 10000 lines, or so total) so I wanted to ask if anyone have an idea as to what I can look at, if anything before posting code?

If you want to have a go yourself, the page is here: www.personaldatabasen.no - the first page is the creation of the config-file, all info should be declared already (yes, I know the database-password is present, there's nothing important there anyway, I'll change it after). If you want to run through it, the first one sets up the config.php-file, then it goes to a "Build database" button, which then fails. Without a meaningful error, which makes me believe that it's not really the creation of the database-tables that fails (all of those queries have an error-reporting function turned on), but something else. I just can't seem to figure out what it is.

 

If it only matters at all, when I clicked 'about us' and 'license' link it shows following error message:

Fatal error: Call to a member function query() on a non-object in /home/..../coreclass.php on line 509

Code (markup):

Assuming that this error didn't happen on your localhost, you would probably start looking at this error. Best answer on Stackoverflow is here: http://stackoverflow.com/questions/...ction-query-on-a-non-object/14822117#14822117

 

Yeah... that has nothing to do with it - it's just some other pages not working because the actual db-connection isn't set up properly, and the tables aren't there.

I added a logging function to the setup-script, and lo and behold, the first error that shows up is the first execution of a query - but it doesn't report anything, it just shows the error from the logging output, not the actual error-information. Here's the code in question, somewhat stripped of a lot of other code:

      $core->dbh->exec("DROP TABLE IF EXISTS `{$prefix}access_log`");

PHP:

First we do a check of all the database tables (with the chosen prefix) to see if they exist - if they do, we delete them - this seems to be working just fine, which leads me to believe that the connection to the database is actually present.
Then:

$create_access_log = $core->dbh->prepare("CREATE TABLE IF NOT EXISTS `{$prefix}access_log` (
         `id` int(11) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY,
         `user_id` int(11) unsigned NOT NULL DEFAULT '0',
         `log_name` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
         `datetime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP,
         KEY `userid_access_log` (`user_id`)
       ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci");
       file_put_contents('../logs/setup_log.txt','created access-log query'."\r\n",FILE_APPEND);

PHP:

This creates the query for setting up the table, and outputs a single text-string to the log file, saying that there wasn't anything wrong thus far in the script.
Then, and this is weird, we have the error: (this is far further down in the script, after all the queries are created)

      if (!$create_access_log->execute()) {
         $info_config = displayErrors($create_access_log);
         $status_config = 'error';
         file_put_contents('../logs/setup_log.txt','ERROR: 1'.displayErrors($create_access_log)."\r\n",FILE_APPEND);
     } // elseif next query and so forth and so on

PHP:

The weird parts here is the following:
It fails, and shows "ERROR: 1" in the log file, but doesn't, for some reason, output the actual error from the displayErrors-function - which has me thinking that there is something wrong somewhere, and I'm just not thinking about it. displayErrors() is a error-function from the $core-db-class, and normally works just fine everywhere else on the page. It looks like this:

      function displayErrors($result,$output = false) {
         global $document_root,$rootfolder,$logfolder;
         $sqlerror = ($result->errorCode() > 0) ? $result->errorInfo() : '';
         if (!empty($sqlerror)) {
           file_put_contents($document_root.$rootfolder.$logfolder.'sqlerror_log.txt',$_SERVER['REQUEST_URI'].' - '.__LINE__.' - '.$sqlerror[2]."\r\n",FILE_APPEND);
         }
         if (!empty($sqlerror) && $output == true) {
           return '<p class="messagebox error visible">'.$sqlerror[2].'</p>';
         } elseif (!empty($sqlerror)) {
           return $sqlerror[2];
         } else {
           return '';
         }
       } // end displayErrors

PHP:

So... halp?

 

Pffff .. If it works on localhost but not on remote host, just a random guess: InnoDB vs MyISAM? File permission? PHP version?

Sorry, I have no better idea.

 

The database is set up with InnoDB, as it should be. PHP version on host is a little bit newer than on my localhost, but nothing should prevent it from running, I've run info without finding anything in particular that should affent this.
I might have to ask them if there is a problem with using PDO to create tables in a database, but apart from that... yeah, I'm a bit at a loss too.

Sidenote: the DROP-statements run, no problem, it's just when it comes to the actual CREATE TABLE statements it crashes hard.

 

Nevermind... I found the problem(s).
Seems there was a little bit more strict settings on the host's server than my own, which resulted in non-fatal errors (and some fatal), which didn't show up in the logs, but which definitely thwarted my script. Among them, the SQL-version running on the host doesn't seem to support FULLTEXT indexing on InnoDB-tables.
Had to throw in a PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION to actually see these things as they happened. Oh, well, a bit of tinkering with the script, and it works now.

 

That's why ANY errors in the logs AND any errors you can trap are so important. When you said "The script leaves a bit of garbage in the php-error.log, but nothing major" -- there is NOTHING that shows up for an error in the logs that qualifies as "nothing major" -- particularly when a lot of what were once warnings are now fatals as newer PHP flavors continue to come along.

Though even just your displayError function is "raising my hackles" with the pointless repeated testing of the same values over and over and over... If the rest of your PHP is like that, I'm not surprised you're having problems both from a code legibility standpoint and an inability to catch errors before you even try to run it.

define('LOG_FOLDER', $document_root . $rootfolder . $logfolder);
define('LOG_SQL_ERROR', LOG_FOLDER . 'sqlerror_log.txt');

function displayErrors($result, $output = false) {

	if (!$result->errorCode()) return '';
	
	$sqlError = $result->errorInfo();
	
	file_put_contents(
		LOG_SQL_ERROR,
		$_SERVER['REQUEST_URI'] . ' - ' . __LINE__ . ' - ' . $sqlError[2] . "\r\n",
		FILE_APPEND
	);
	
	return
		$output ?
		'<p class="messagebox error visible">' . $sqlError[2] . '</p>' :
		$sqlError[2];
	
} // function displayErrors

Code (markup):

Should be functionally identical, but far more efficient. Don't make the extra variable until you actually need it, short circuit out EARLY if there's no error, and don't recheck the same condition three blasted times! Note that I use define so that you don't need to say global and you don't have to waste time doing string addition every blasted time you call the function.

I'd also at least consider passing the error CODE to your log file... not all errors have proper meaningful text associated with them for ::errorInfo to return. (I learned that one the hard way about five or six years ago -- non-zero error code with no text?). Also not sure __LINE__ is going to be meaningful... I'd be passing a name/title string as to which query is failing to that.

That "visible" class is also a bit troubling in a "separation, what's that?" kind of way...

-- EDIT --

Also, you don't seem to be passing values to the CREATE query (not that one EVER should), so why in blazes are you using :: prepare?

 

Thanks, @deathshadow - this is a work in progress, and I've built it a bit "here and there", so it's room for improvement. I've taken your way of doing the error-reporting, and implemented it, and also added the actual query failing, so that it's a bit easier to pinpoint what went wrong.

 

So a bit premature to go off on you for your illegible thin glyph narrow webfonts and broken inaccessible incomplete form, much less abusing placeholder to do label's job?

Don't get mad, I'm just saying; don't believe it cause I'm saying it, believe it cause I'm telling you.

 

Are you talking about the login-form? If so, I'm very well aware of the missing labels All other forms have them, it's just the login-form that doesn't. Working on redesigning the login so it adhers to good practice.
I like my fonts, thank you very much, they're perfectly legible on every platform I've tested them on
But yeah, I know there's a few issues with contrasts and colors. I might fix them, I dunno yet. Currently it's not really important.

 

Hence the tongue sticking out smiley, was more a gentle ribbing as I figured you were aware of most of that.

 

Yeh, I usually know when I'm breaking the rules. Currently I'm rewriting the CSS for the site to cater for a few design-changes I decided on (weird what actually GETS DONE when you're chasing elusive bugs in the code...) and getting rid of... a bit of bloated CSS-crap.

 

Apparently you did not test them here. See the posted image:

 

Holy crap that looks bad - what browser and resolution is that? Here's how it looks here:

 

@mmerlinn 's screencap is pretty much what I'm seeing here in FF and Vivaldi. Win 7, 20px as the system default font (aka 120dpi/125%/whatever they're calling it this week).

Illegible grey on white, illegible white on blue, difficult to read poorly rendering goof assed webfont (which is why I'd NEVER use webfonts on flow text)...

... though your screencap isn't much better with the painfully too wide max-width and lack of consistent paddings.

Here's what I'm seeing in FF... which is pretty damned useless to me as a user. Headache inducing even.

http://www.cutcodedown.com/for_others/PoPSiCLe/broken/aboutPage.jpg

 

Hm. I fail to see how that would be headache-inducing, but that might just be me, of course. Seems to render perfectly fine to me, all readable and such. But I've considered changing the main font to just be some standard sans-serif font, and keep the open-sans for headings and such only.
I don't have limited vision of any kind, so that might be why I don't think "illegible" is the word to describe the grey on white text, although the white on blue text is a bit washed out. Maybe I'll redo those, at least.

@deathshadow: WHY is that screencap useless to you? I would like to know why you think it is, and what makes you say it is - by that, I mean, why do you think it's headache-inducing, and is there a reason for that pov? I've tested the looks on a few hundred users, without any complaints about color-choices - granted, those users are all in their late teens to late 20s, with no serious vision-problems (that I know of) apart from perhaps nearsightedness / wearning glasses, and maybe the occassional color blindness.

 

The massive gap between characters in the headings makes it hard to see word-breaks, as does the all-caps compromise legibility on those. The "thin glyph" fonts effectively reduce large display viewing distance contrasts below accessibility minimums (so unless I set back to 96dpi and keep my head 6" from the screen, the choice of font screws it regardless of how much I zoom), the blue on white is effectively invisible (as supported by the numbers, again check the blasted WCAG!), if there were more than two lines the painfully wide max-width on that bottom paragraph would make it incomprehensible and it's an eyesore from a lack of edge padding.

Let's talk that blue and white... you've got #239DE0 as the background, that's a luma of 128 which means neither extreme of black or white is acceptable for text on that colour; hence why you can't use that colour -- ever -- for an accessible background. AGAIN... 50% luma is the minimum (WCAG AA) on a raster font, you go thin glyph with font smoothing you're suddenly looking at 66% minimum (WCAG 2.0 AAA) and 80% ideal.

Y == 29.9% Red + 58.7% Green + 11.4% Blue

As per the YCbCr ITU-R BT.601 formula (which came into existence after massive study of how the eye works) -- Which of course is why Adobe's using print Luma makes their values useless for web work. (the difference between reflective and emissive light sources)

That thin glyph webfont even at 120dpi/20px browser scale is making stems of 117 luma on the high end and 166 on the low end thanks to font smoothing, so on white that's anywhere from slightly over the minimum to far, FAR under the minimum!

Good rule of thumb, if you test a font as font-size:20px and the bars/stems aren't consistently rendering 2px wide with at least 1px of that 70% ideal on a cleartype system, it's NOT a font you should be using on a website! (laughably, every google webfont I've seen fails this test -- I swear the artsy fartsy types making fonts right now have a vendetta against legibility)

Something compounded by it also being a narrow font -- there's a reason the majority of fonts have an "H Ratio" of 2:3 as a minimum. That sub-3:5 H ratio of that font means it's below acceptable minimums for roman character text. This makes your massive letter spaced areas harder to read, and the normal areas painful.

I'm reminded of just over two decades ago when a girl I was dating was part of her college theatre group, and the graphics art teacher made them a logo for some t-shirts to sell after every show... and they didn't sell all that well as nobody could figure out what in blazes a gomuddy grueue was. SUPPOSEDLY it said "Comedy Crew" -- sure it did. Again, doesn't matter how fancy something is if it compromises legibility. What you have isn't THAT bad, but it's certainly treading into that territory. Just be glad you don't have words like therapist in a heading there...

... and of course don't forget that italic automatically doubles the needed contrast levels, particularly if the font itself does not provide a pre-rendered italic with proper hinting. (which few if any webfonts do) and instead rely upon the rendering engine to skew the coordinates.

That font probably looks great on a Quackintosh / OSuX with its "Let's make everything bold and blurry", but don't get me started on how cleartype on linsux is probably mangling that mess -- what with its habit of kerning characters like a sweetly retarded meth addict rhesis monkey! (seriously I've seen kindergarteners space their handwritten block text more consistently than cleartype manages... one of the many reasons I can't use linsux as a desktop OS)

So yeah, problems. Simple fact is the majority of webfonts == /FAIL/ for flow text, and the WCAG rules for colour exist for a REASON, USE THEM!

 

Hm. Either my eyesight is way better than yours, or there's something else afoot. My main screen is a regular full-hd lcd, nothing fancy, and I'm running Windows at standard dpi, sitting about 1m from the screen (standard wall mount over the desk) and I can read it, no problem. Also, the screenshot you gave didn't have any of the problems mmerlin posted (which I assume might be a Linux computer). While I do understand the WCAG minimums, I'm not a fan, as the allowed color combinations leave a lot to be desired design-wise. I'm not entirely sold on the fonts, though, so I might see what I can do about them at least on the flow text. (The main reason for the choice of fonts were specs from the original company requesting the software, but since they're no longer in the picture, no obligation to keep the fonts either).

 

More than likely. Painfully nearsighted now which is making me increasingly aware of why all those things I was told about UI design 25 years ago from things like the Windows and MacOS interface guidelines now makes sense.

You know, those massive studies and results that arsty-fartsy types have somehow convinced the suits to pitch in the trash with "who cares if people can use it" attitude? See how Winblows 10 and OSuX are less useful to accessibility needs than Win98 or MacOS 7 were? You'd almost think they put art faygelah's who know jack shit about usability in charge... OH WAIT!!!

What resolution and size? "Full HD" could mean anything. I typically sit three feet from a 27" 2560x1440 at my workstation, though in this case I'm on 1920x1080 on a 17" lappy at about two feet.

Looks near identical to me apart from his image having more artifacting, likely from higher compression. All those issues I pointed out? That's WHY it's rendering like taht.

You mean art-wise, since usability and accessibility are supposed to be PART of design. In fact, they are SUPPOSED to take precedence OVER the artsy fartsy bullshit since it doesn't matter how pretty it is if it's making it unusable for users!!!

Again, it's pathetic how people seem to think that dicking around in photoshop or screwing around with appearance is the "sole aspect" of design -- when that's not design, that's graphic arts. It's like hiring an oil painter instead of an architect; there's a word of difference between architectural design and Bob Ross' happy little trees.

If you have an architectural designer, it means they keep things like entrances, exits, foundations, and materials tolerances in mind if they worth a flying purple fish. If you have an automotive designer they know about how body parts fit together, materiel tolerances, aerodynamics, and a host of other factors... so how the **** is it that most web designers willfully ignore usability, accessibility, user studiies, the standards of HTML and CSS, and proper guidelines and established good practices? At that point it ceases to be "design" and is instead Graphic Arts.

Which means whoever made those "specs" knew shit about shit, and it's probably a good thing they're out of the picture. Lemme guess, print background marketing or graphics folks? You know, the LAST people who should be included in design discussions?

 

Full HD == 1080p (that's the definition of "full HD" at least - although a lot of other resolutions misuse the term) - 27" 1920x1080p monitor, between 1m and 60cm away from it (movable mount) - I also have a 16" laptop with same resolution, which I usually have on my lap while working on it, so... about 2 feet? So yeah, my eyes are probably better, although I am nearsighted.

My point about the image you uploaded is that I can read it without any trouble, it seems fine to me (although the one mmerlin posted was very artifacty). But if you see that image more like the image posted by mmerlin, then yes, I do understand why you think it's hard to read.

And yes, I do mean "art" as that part of design - the look of the site, nothing else. I am very aware that design is an overall concept, taking into account both looks, function, accessibility etc.
But, again, I'm currently working on something that won't be a general website, nor will it (most likely) be used by a lot of people with sight-issues (at least, VERY few) - not that many people with severe sight issues working in the bar- / serving-industry.

And yes, the spec-sheets for the original contractor does read quite a bit on the print-side, without that much understanding for, or adherence to, web design. Hence most of the font choices etc. is built on freely availble fonts for use in print, and style is built on using these fonts for almost every project - the one chosen was the one that looked least horrible on a screen (without having a too bold look, which I personally find a lot more annoying than a font too thin).