[Form not submitting if text field is too long/large (PHP & MYSQL)]

The mysql_ extension has been depreciated for quite a while now, and as of the current release of PHP (v7) it's no longer supported at all.

 

PDO is a newer library (well it's really an abstraction but that's not important) that does all the same things mysql_ did - only better.  As I said, another option is mysqli_ (the i is for improved) which is also acceptable, but I personally prefer PDO because it works with more than just mysql.

 

I have posted a simple example of PDO use in another thread, but for ease I'll post another here with some comments for you:

 

$con = new PDO('mysql:host=yourDBHost;dbname=nameOfDB', 'dbUserName','dbUserPassword');
//that establishes the connection to the database
$sql = "SELECT some, fields, that, you, want FROM tablename WHERE condition = :match";
//that names a base query string to use, notice that the value that the condition has to match is entered as :match - the : notates a parameter that needs to be bound
$stmt = $con->prepare($sql);
//that prepares the query sting statement for parameter binding
$stmt->bindParam(':match', $yourVarToMatch, PDO::PARAM_INT)
//that binds the value of $yourVarToMatch to the placeholder :match set in the query string and tells the PDO class that it is to be an integer.
$stmt->execute();
//execute the statement
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);
//fetch all the results into the $results variable in the form of an associative array
$errors = $stmt->errorInfo();
//pass any error info into the $errors variable - errorInfo() returns an array.
if($errors[0] != '00000'){
var_dump($errors);
}   // errorInfo() will return a value of '00000' as the first item in the array if the query was a success, if this isn't the case we want to know what wen't wrong
else{
var_dump($results);
} // if everything wen't OK let's see the results we got back

That's all there is to it.  Obviously the var_dumps() are just for debugging, you can handle the contents of $results and $errors like you would any other variable. 

 

There are other nuances of PDO, such as when run a query that does not require any parameters to be bound you would do things a bit differently, and there are a number of options that you can - and in a production setting should - set during the initial new PDO() call, but that should be enough to get you started with it.

[Form not submitting if text field is too long/large (PHP & MYSQL)]

Y'all need to stop using mysql.  you should right now take this opportunity to re-write that using PDO (or mysqli if you really want).

[how this logic work? form handling]

your if statement is too loose, all it's checking is:

if jobtitle is empty, OR any other field has content then throw the error, you need to add some more complexity

 

if($rjobtitle1 == '' &&( $rjobcompany1 != '' || $rjobcity1 != '' || $rjobfrom1 != '' || $rjobto1 != '')){
//this checks that if the jobtitle is empty AND anyother fields have any information in them then throw the error
$error[] = "you need to add your job title to go with the company information";
}
elseif($rjobtitle1 != '' && ($rjobcompany1 == '' || $rjobcity1 == '' || $rjobfrom1 == '' || $rjobto1 == '')){
//this checks that, if the jobtitle has content and none of the other fields have content then throw the error
$error[] = "you have not told us some or all the info about the company that your job - {$rjobtitle1} - was with, please provide these details (all fields are required)";
}

And so on.

[A data structure problem !]

Again, in my eyes, the obvious answer is triggers and stored procedures within the database.  But I get the impression that @Jacques1 was offering his solution instead of this approach, so I'm disinclined to suggest you hybridise (or bastardise - depends on your point of view) the methodologies.  I'm sure @Jacques1 will elaborate further on how to properly solve your issue.

[getting error on submission]

You are trying to insert null values into columns that you have set in the DB to not accept null values. Either ensure every required field has a value or change the settings in the table if you want to allow null value submission.

[Get All Records From Table one Joining other table]

Well I don't know what the e.event = "Arrival" is for, but the only way I can think of to do what you are trying is with a subquery join. Something like the following:

 

SELECT CONCAT(fname,' ',lname) AS fullName, event_time, event_date, event
FROM user_table AS u
LEFT JOIN
(
  SELECT uid, event_time, event_date, event
  FROM event_table AS ev
  WHERE event_date = '2016-07-05'
) AS e
ON u.id = e.uid

[Get All Records From Table one Joining other table]

so you want all users, regardless of whether they have an entry relating to the date you enter, and you want to mark the ones that don't have an entry for that date as absent.  Is that right?

[Get All Records From Table one Joining other table]

I don't understand, if event_date is irrelevant why to you have to use it? And if you want users with event "null" why do you include e.event="Arrival" in your where clause?

[Starting with PDO select statement]

Here's an example PDO Select statement for reference:

$con = new PDO('lib:host=host;dbname=dbname','usr','pwd')
$sql = "SELECT name FROM user WHERE UID = :uid";
$stmt = $con->prepare($sql);
$stmt->bindParam(':uid',$id, PDO::PARAM_INT);
$stmt->execute();
$result = $stmt->fetchAll(PDO::FETCH_ASSOC);
var_dump($result);

There are variants on how to bind parameters and how to fetch results, but this is the simplest way that is closest to what you already tried. I also altered the query to show one way of how you would bind a parameter to a prepared statement.

 

Hope it helps some.

[Building Theme System and Implementation]

 

 

Anyway, I'm starting to think this is hopeless ...

That's what I love about you @Jacques1 - your such a ray of sunshine! 

 

I haven't hit an issue where I need to hack a theme yet, but I will admit a huge lack of experience in this so... could you explain why it's limited to do this?

[Building Theme System and Implementation]

Does the actual content change between themes? Does one theme get different about us info than another? does one theme get a different contact us form?  If not then you only need to change the css, at most the css and a javascript file if you are using js to create some of the UI elements. If you have designed your pages properly then there is no need to use multiple copies of the html as all that should be in that is the core data.

[Building Theme System and Implementation]

What exactly changes between themes that you need to re-write all the content every time?  Normally I would do something like:

 

----------------------------------------------

wbsite.com/index.php

website.com/about.ctnt

website.com/contact.ctnt

website.com/css/primary.css

website.com/css/theme/clearWhite.css

website.com/css/theme/fancyBlue.css

website.com/css/theme/dangerRed.css

website.com/script/php/loader.php

website.com/script/php/conBroker.php

website.com/script/js/myCustom.js

website.com/libs/js/jquery-min.js

------------------------------------------------

 

Have a theme stored in the DB against a user login and then load in the relevant css based on that, or clearWhite.css as a default if no DB results are returned for a theme. Here's some brutally over-simplified example code:

 

 

//inex.php ---->
<?php
requre_once(loader.php)
if($user){
  (!empty($user->theme)) ? $userTheme = $user->theme : $userTheme = 'clearWhite.css'
  $themeLink = '/css/theme/'.$userTheme
}
else{
$themeLink = '/css/theme/clearWhite.css';
 
$header = <<<HTML_CUST_HEAD
<head>
<link type="text/css" rel="stylesheet" href="/css/primary.css />
<link type="text/css" rel="stylesheet" href="{$themeLink} />
<script src="/libs/js/jquery-min.js"></script>
<script src="/script/js/myCustom.js"></script>
... rest of head data
HTML_CUST_HEAD;
//...
echo $header
//...
?>

 

You shouldn't need multiple copies of all the pages for all the themes.

[help with associative arrays]

OK, I think it's because you have the STABBR and PREDDEG arrays on the same level as the "University" array, so when it's going through the results it's hitting these array key names and throwing our warnings because they don't match whet you are asking it to display.  Try:

 

<?php if($this->_tpl_vars['row']['University']){echo $this->_tpl_vars['row']['University']['DisplayValue'];} ?>

[help with associative arrays]

try changing to:

<?php echo '<pre>'; var_dump($this->_tpl_vars['row']); ?>

and see what comes out of that

[help with associative arrays]

In fact, having had another look over the Smarty docs I think it's actually more like:

{foreach from=$Grid value=row}
  {$row.University.DisplayValue}
{/foreach}

If that doesn't go deep enough you could try:

{foreach from=$Grid value=row}
  {foreach from=$row value=Uni}
    {$Uni.DisplayValue}
  {/foreach}
{/foreach}

::Edit - missed off half the post

[help with associative arrays]

Ahh, I've never used Smarty before, but casting an eye over the docs it looks as though it should go something like this:

{foreach from=$Grid value=$row}
{$row.University.DisplayValue}
{/foreach}

::Edit - forgot to close foreach

[help with associative arrays]

Going for displaying all the DisplayValue values something like the following should work:

 

 

foreach ($Grid.row as $key => $uniArray){ //iterate through the top level - $uniArray holds each "University" array one at a time
  foreach ($uniArray as $k =>$uni){ // iterate through the items of each "University" array (Caption / Value / DisplayValue etc...)
    if($k == 'DisplayValue')){
      echo $uni['DisplayValue']
    }
  }
}

[help with associative arrays]

when you say echoing "only the university" - what do you mean by that? Just the name? (as in the $array[...]['University']['DisplayValue']) or do you mean the full details of every $array[...]['University'] sub-array?

[horizonatl navbar problem]

try adding the following:

 

...
 nav{
display:inline-block;
...

[Password_Hash And Salt Uniquess]

 

 

128 is the bit length of bcrypt salts. It has nothing to do with randomness. You'd have the same limit if you used sequential salts.

now your just showing off.   

[Password_Hash And Salt Uniquess]

Yeah, the first bit was what I was asking about.  I wasn't sure what the word length of URANDOM was, so didn't know.  Still 2^128+1 doesn't really register to me, so I fond this page that helps conceptualise the size of that number:

 

http://bugcharmer.blogspot.co.uk/2012/06/how-big-is-2128.html

[Password_Hash And Salt Uniquess]

@Jacques1 : thanks for the link, though I'd be lying if I said I understood half of the formula on that page.  It doesn't look like the answer to what I was asking though.  Assuming URANDOM is being used to create the salt, how many times would the same password have to be put trough the same algorithm in order to guarantee a collision?

 

Is that what you answered?

[Password_Hash And Salt Uniquess]

double quotes create what I call "loose" stings, any PHP special chars - such as $ are parsed as code whilst within the string.  single quotes make absolute strings, so everything inside them is taken as a part of the string literal (with the exception of the escape character). 

 

see here for more detailed info on PHP strings.

[Password_Hash And Salt Uniquess]

@requinix I'd like to see the numbers on how many users it would take to guarantee a duplicate hash assuming every one used the same password. Also I like using phrases for passwords over actual words eg. "I used to live at 221b Bakers Street, but got fed up with Danger Mouse ruining all the letters I put in the post box" would be a good one 

[A data structure problem !]

You're quite welcome, and no, @Jacques1 was saying that you should use more tables, enforcing referential constraints to ensure that only relevant data is viable.  Each item in his list of possible relations is a table with the content of the parenthesis the relevant columns to build relations between the tables:

 

Possible relations:

• staff(staff_id, last_name, first_name, ...)
• assistant_managers(staff_id)
• deputy_managers(staff_id)
• applicants(application_id, last_name, first_name, ...)
• manager_recruitments(applicant_id, role)
• assistent_manager_recruitments(applicant_id, role, approved_by_manager)
• deputy_manager_recruitments(applicant_id, role, approving_assistent_manager_id, approved_by_manager)

 

It's as I said, there's no way to give a definitive "This is how it should be done" without the full information. Both @Jacques1's method and mine have different ways of doing things and we could argue till the keys came off our keyboards which one is "right" but at the end of the day, like so much of development, there is a massive amount of subjective preference applied to every point of view.  That's why there is a need for best practices and why, even the best practices that do exist only stand as guidelines rather than referential rules. An analogy would be to say that "Cast concrete is the best material for building houses, from this day forward all houses must be built of this material." That dog just aint gonna hunt.