Axeia
-
Posts
717 -
Joined
-
Last visited
Never
Axeia's Achievements
Member (2/5)
0
Reputation
-
PDOStatement problem that doesn't seem to throw an error..
Axeia replied to Axeia's topic in PHP Coding Help
After wasting hours on this I found the cause. The SQLite database I'm using makes use of foreign keys. The host is running version 3.3.7 of SQLite which does not support foreign keys and isn't compatible with databases containing these it seems. Found out by recreating the entire database using PDO statements, downloading the database and then finding out tables with foreign keys aren't created. -
PDOStatement problem that doesn't seem to throw an error..
Axeia replied to Axeia's topic in PHP Coding Help
Thinking it might be a problem due to different versions of the SQLite library I tried deleting the database both on the host and locally. Similiar result, locally I get a PDOStatement with the original query but on the host this does not happen although the database is created just fine. -
Hello, I'm using PDO to connect to a SQLite database. Locally under wamp everything runs fine, on my testserver running openSUSE 11.4 / apache / php5 everything is running fine as well. On my host however it doesn't seem to work at all, and I'm not getting any useful information from PHP either. I'm using the code below in the __construct of my database class. $dbLoc = dirname(dirname(dirname(__FILE__))).DIRECTORY_SEPARATOR.'external_access_denied'.DIRECTORY_SEPARATOR.'ic.db3'; try { $this->db = new PDO('sqlite:'.$dbLoc); echo '<pre>!'.print_r($this->db,true).'</pre>'; $prep = $this->db->query('SELECT name FROM sqlite_master'); echo '<pre>!'.print_r($prep).'</pre>'; echo $prep instanceof PDOStatement.'<br/>'; echo '<pre>!'.print_r($prep->fetchAll()).'</pre>'; } catch( PDOException $e ) { echo 'a----'; Util::logError(__FILE__, __LINE__, $e->getMessage()); } catch( Exception $e ) { echo 'b----'; Util::logError(__FILE__, __LINE__, $e->getMessage()); } The output I get on my host: !PDO Object ( ) !1 Fatal error: Call to a member function fetchAll() on a non-object in*snip*ncludes/classes/Database.class.php on line 42 line 42 is "echo '<pre>!'.print_r($prep->fetchAll()).'</pre>';" from the code example. Locally I get !PDO Object ( ) PDOStatement Object ( [queryString] => SELECT name FROM sqlite_master ) !1 1 followed by a long array with the query results. -- So what is going wrong? I'm not getting PDOStatement object on the host even the PDO object is there. instanceof seems to think it's a PDOStatement, but print_r thinks different. If anyone could shine a light on this I'd be impressed.. rather flabbergasted myself.
-
Absolute positioning should be avoided where possible, not as big a no-go as using tables for layout but pretty close. Centering content is as simple as doing something like <div style="width: 700px; margin: 0 auto;"></div> So a fixed width, and margin: 0 auto (applied on a block element such as a div). Your labels aren't asociated with the input elements, how to do this can be found on the w3 site (a label has a for attribute pointing to the name/id of an input element). Is the contact form and the image next to it supposed to be behind the border of the site itself (Using Firefox 4.0.1)? Also, the second paragraph on the site fall behind the images. You should wrap those images used as a heading in a heading tag (h1-h6) so Google and screenreaders know it's a heading, good job at giving them an alt tag with more or less the same text though! --- Your google 'speed rating' could have gone down because connections are expensive, every seperate file on the site needs to set up a connection (all images, all external javascript/css files). So one big image (filesize) wise can be faster to load than 3 seperate smaller ones. So indeed CSS sprites would be adviseable. You could do something similar for the javascript, combined everything except for jquery itself in one big file. I see you're including all the javascript in the <head> section while it all seems to be unobtrusive jquery based, try moving it to just before </body> tag so it loads after the rest loads, this way the stuff the browser needs to render the page loads up first and the page will be faster to load. Another thing that's as big a no-go as using tables for layout is using <font> tags, and you're using them. You should use a <span class="x"></span> tag instead and do all coloring/font-family usage etc in the stylesheet. I guess you're working on it atm as none of the javascript is working and my firebug console shows more than one error. Good luck with the site, I do like the looks.
-
Headings are used properly which is nice to see, some other things could use improvement though. http://www.indigo-self-assessment.co.uk/Who-completes-a-tax-return.html alt="book_image", if the image doesn't convey information but is just there for decoration leave the alt tag blank. http://www.indigo-self-assessment.co.uk/Instant-Quote.html The form relies on javascript, you should never rely on javascript if it can be avoided, poses accesibility problems. Moving the javascript to an external file would also be a good idea. Another thing I noticed is that this form lacks labels, if you something like the code below most browsers will make a click on the label select the radiobutton in it. <label><input type="radio">Yes</label> On the refer a friend page you did use labels for the text inputs, but not in a way that makes sense. You have: <tr> <td height="40" bgcolor="#9F7DCE" class="Quotation" style="padding:2px 6px 2px 6px;">Please provide your Name</td> <td valign="middle" bgcolor="#D5D5D5" align="center"><label> <input type="text" id="name" name="name"> </label></td> </tr> While it should be: <tr> <td height="40" bgcolor="#9F7DCE" class="Quotation" style="padding:2px 6px 2px 6px;"><label for="name">Please provide your Name</label></td> <td valign="middle" bgcolor="#D5D5D5" align="center"> <input type="text" id="name" name="name"> </td> </tr> These tables are pretty bad btw, tons of bgcolor tags and inline styling.. you oughta move that to a stylesheet and redo these tables by hand as the code seems to be spit out by some program that isn't doing a very good job at it. http://www.indigo-self-assessment.co.uk/Our-Process.html You really should use a ordered list here instead of divs, divs don't mean anything while a list means there is a relation. Since there is a order to things it makes sense to use an ordered list. I guess the captcha on the contact page is a placeholder? Static link and no text on it.
-
Since you're listing Linux alternatives you may want to consider showing for which one of the major desktops the application is intended. For example when I search for "msn" it returns: Pidgin, Empathy, Kopete and aMSN. Chances are that if I'm using the Gnome desktop I'd be interested in both Pidgin and Empathy but wouldn't like Kopete much. It would also be nice if the rating was display directly instead of having to click each application to see which is the most popular. (could be that you're sorting by popularity atm, I don't know and neither would anyone else visiting). Quick and dirty mockup below.. icons are far too large though, but it gets the idea across. [attachment deleted by admin]
-
Just look on the bright side, the documentation for the 'money' type reads: "Note: The money type is deprecated. Use numeric or decimal instead, in combination with the to_char function. " So you are now future proof For presenting the output back to the user PHP comes with a money_format function of its own.
-
an easier way (that takes way less code) would be to wrap what you want to replace in something like <div id="replaceMyContent"><div id="status"></div></div> and then do a <a href="javascript:document.getElementById('replaceMyContent').innerHTML = '<textarea>Hi, Im new</textarea>';">edit</a>
-
I think it's possible using variable variables . As you may have guessed from the name, they just add to the confusion and are generally considered bad practice. Stick to using $_GET.
-
Like javascript, PHP is also able to manipulate a page via the DOM. So there is existing functionality to do the job it does however require well-formed HTML. The documentation page of the removeChild method also has an example of how to load a file. (for HTML use $doc->loadHTML() instead of $doc->load() - XHTML should be loaded as XML)
-
If you simply want to read out the values, this is the most basic example I can come up with. <?php if( !isset( $_POST['food'] ) ) { echo ' <form action="" method="post"> <label for="food">Which vegatable would you like for dinner?</label> <select name="food[]" MULTIPLE> <option value="carrots">carrots</option> <option value="peas">peas</option> </select> <input type="submit" />'; } else { foreach( $_POST['food'] as $veggy ) { echo $veggy."<br/>"; } } ?> [edit] Forgot to explain The magic part is in the name attribute, it has to end on []. PHP automatically creates an array out of form elements whos name ends on [].
-
Then pass the parameter to do that to the construct or create a method public function setDatabase($db) { $this->_db = $db; } Although if $this->_db is vital for the blogPost class (which I suspect it is) it belongs in the construct. As a few hopefully constructive tips.. tip #1 PHP(5) supports type hinting so this works as well: __construct(database $db) The more strict you can get the better imo. (Als provides more useful errors when you pass in a parameter of the wrong type) tip #2 You may want to stick to the general PHP (and java and probably other programming languages as well) code convention to start classnames with a capital letter, so Database and BlogPost instead of database/blogPost. (this is gonna be a rather late reply.. left this open in a tab for half a day)
-
'non selected' data from elements that give an array are lost when submitted. That would be your <select multiple> but also for example <input type='checkbox' value='cows' name='opt[]' /><input type='checkbox' value='sheeps' name='opt[]' /> There is no way getting around this besides either sticking all options in <input type='hidden' /> as well, or by simply using static code (or a query) to retrieve the information like you did on the original page. I think HTML5 might offer a solution for this, but too early to use and I'm not even sure if it did.
-
if/else trying to verify correct email format
Axeia replied to enhanced08's topic in PHP Coding Help
If you have a recent version of PHP there is the following nice filter_var function available (PHP >= 5.2.0) if( filter_var( $email, FILTER_VALIDATE_EMAIL ) !== false ) And this by the way is like saying "Please hack me". $email=$_POST['email']; $query="SELECT * FROM mailing_list WHERE email='$email'"; $query="INSERT INTO mailing_list VALUES ('','$email')"; $_POST = user data = used directly in a query = you're going to get hacked. Please read up on SQL Injection. In short, if you don't get data from a trusted source use mysql_real_escape() .. or be paranoid and always used mysql_real_escape(), as the saying goes, Better safe than sorry! -
[Edit] Ignore me, guess you're using some class with the escape method as you're using it in your own example as well. I'd be somewhat amazed if that worked for you. 'escape' isn't a method of the PDO class. (I assume $db = new PDO is somewhere in your code) If you're getting an error about that, use $db->quote instead. Although as stated on the page mentioned above you're probably better off using a prepared statement.