cyberRobot

Note that URL include wrappers needs to be enabled on the server for absolute paths. As an alternative, you can use a root-relative path. The require_once, require, etc. statement just needs to start with $_SERVER['DOCUMENT_ROOT']

In the query, have you tried using the ORDER BY clause to sort the matches. I assume that "last matches" means that you are looking for the newest entry(ies), correct? If so, I imagine you have a date field to indicate when a record was added. That field can be sorted in descending order to make the newest entries appear first in the result set. Then you just need to use the LIMIT clause to have the query return the number of results you want.

The empty() function also considers values like the number 0 as empty. That could be problematic with some forms. With that said, I think the goal of Jacques1's code is to make sure the necessary parameters exist. Any validation beyond that happens elsewhere. If a field is required, you would run a second check to make sure the variable isn't blank. I personally do something like this: if(!isset($_POST['someVariable']) || $_POST['someVariable']=='') { //flag error } ...which, of course, can be simplified with Jacques1's code.

Topic locked. The OP created a new thread here: https://forums.phpfreaks.com/topic/302542-wordpress-help/

As others mentioned, the script is out of date. The mysql_* functions have been removed in PHP 7.0. The session_register() function was removed in PHP 5.4. And that's just to mention a few of the problems. If you choose to continue, hopefully just for educational purposes , is PHP set to display all errors and warnings? You can make sure by adding the following to the top of your script during the debugging process: <?php error_reporting(E_ALL); ini_set('display_errors', 1); ?>

That seems fine. Did you try it out? Note that I'm unsure about the part highlighted below: That suggests the output would happen inside the function.

Perhaps the following will help: http://php.net/manual/en/functions.arguments.php There are some examples on how to display something based on the function arguments. You just need to figure out how to do the math aspect.

In addition to checking for PHP errors, as suggested by ginerjm, you may also need to see if MySQL is throwing errors. To see if the query failed, for example, you could use the following: $sql= "INSERT INTO stock (sid,stcode,stname) VALUES ('','$_POST[code]','$_POST[name]')"; mysql_query($sql,$link) or die(mysql_error()); And just to clarify what benanamen mentioned, the mysql_* functions were removed in PHP 7.0. So your code needs to be updated in the very near future. More information about the alternatives can be found here: http://php.net/manual/en/mysqlinfo.api.choosing.php As for the security aspect, use caution when dealing with data that users can tamper with, such as the information collected in an HTML form. The code posted, for example, is susceptible to SQL injection attacks. To protect yourself, with the old mysql_* functions, you can use the mysql_real_escape_string() function. More information can be found here: http://php.net/manual/en/function.mysql-real-escape-string.php When switching to PDO (or MySQLi), you will want to look into prepared statements.

Good catch!

Could you provide a little more information as to what the following means: Do you get an error message? If so, what's the exact error? Does it do (or not do) something you expect? Note that you need to call "exit" after performing a header redirect to prevent anything else in the script from executing. header("Location: test5.php"); exit; Also, the script only appears to be checking if the email address exists. You need to make sure the password associated with the email address matches. In case you are not aware, PHP has a function for validating the email address. More information can be found here: http://php.net/manual/en/filter.examples.validation.php And here is some information on password hashing: http://php.net/manual/en/faq.passwords.php

You could start here: http://php.net/manual/en/features.file-upload.php

And as I said before, this is tabular data. So using an HTML table that's marked up is acceptable. While some may say that you need to use CSS, I'll continue following the advice put forth by the website accessibility community. :-)

What I'm referring to can be accomplished with plain HTML and PHP. Basically, a user is presented with a blank form. They fill it out and hit submit. Then PHP processes the submission. If it finds a required field that was left blank, PHP builds the form again and incorporates everything the visitor entered before, along with an error about the missing data. I don't see why those form fields, with or without data, cannot be displayed in an HTML table. As long as the proper coding is added to make it a data table, people with assistive devices will know if a field contains a value or is blank. They also get a bit more information about the fields because of the data table. They will know who many rows and columns the table contains, for example. So if the form has one of those "add more fields" features, the person with a screen reader, for example, could make sure they have enough rows to entering their data.

The OP's form asks for a series of school [names], student [names], and class [names]. That data, once collected, would likely be displayed in a data table as described by NotionCommotion in Reply 11. Of course, the real data wouldn't say Student1, Student2, etc. So if the collected information works as tabular data, why can't the input fields be displayed with an HTML table? Is it because the input fields are probably going to be empty in the beginning? If so, let's say a visitor fills out the form, but they forgot a required field. The form would hopefully be displayed again for the visitor to enter the missing data. The fields now contain data. Shouldn't that be treated as tabular data...assuming the table is formatted to meet accessibility best practices? With all that said, I am fully aware that the code posted by the OP is not accessible.

...for layout tables. I still think we're dealing with tabular data. So I guess we'll have to agree to disagree.

Also, that accessible tables article says the following: As far as I'm aware, the main reasons layout tables should be avoided is twofold. Tables can be problematic for people that use assistive technologies. And CSS is now widely supported, so using HTML tables to layout a page is no longer the best option. Is there something I missed that would suggest that tables cannot be used in a scenario like the OP put forth?

That pages talks about how assisitve devices work with regular HTML tables, which don't have special markup. It explains why layout tables can be bad, which I agree with. But we're not talking about layout tables, at least not in my opinion.

The article is titled "Creating Accessible Forms". ARIA, the technique described in the article, was created to make web content more accessible to those using assistive devices. The <label> tag is used to connect a form label to the corresponding input field, making the form more accessible since the assistive devices do not need to guess which label goes with which field. The introduction on the page talks about the shortcomings of the <label> tag. And then goes on to show an ARIA method that takes the HTML table to make the form accessible.

Since the OP is collecting tabular data, an HTML table can be leveraged to make the form more accessible to those using assitive devices, like screen readers. More information can be found here: http://webaim.org/techniques/forms/advanced

Seems like a fair point. And I'm truly asking. Would you use an HTML table in that scenario?

For what it's worth, I agree with NotionCommotion. While the data doesn't exist yet, the form is asking the user to enter tabular data. What if the form fields are populated with some entries for the user to edit? Would you use an HTML table then? You have tabular data. It's just presented through form fields.

As far as I'm aware, whether a page prints with background colors is determined by the user's browser. In Chrome, for example, there is a "Background Graphics" checkbox in the print dialog under "More Settings".

Do you plan to use plain JavaScript, jQuery, etc.? With plain JavaScript, yYou can try something like the following: http://www.aspsnippets.com/Articles/Show-Hide-DIV-with-TextBox-based-on-DropDownList-Selected-Value-Selection-using-JavaScript-and-jQuery.aspx Of course, you may want to make some tweaks so the forms still work for visitors who have JavaScript disabled. You can do this by showing all the forms up front. Then use JavaScript to hide the content you don't want displayed until Yes or No is selected.

For what it's worth, the following looks promising: http://help.adobe.com/en_US/livecycle/9.0/LiveCycle_Designer_Scripting_Basics.pdf

In case it helps, I currently have LiveCycle Designer ES2 (Version 9). And I meant to mention that XFA stands for XML Forms Architecture which is used to create dynamic PDFs.