requinix

style="color: #009000"

An unset upload_tmp_dir is completely okay. What are you trying to install? What error is it giving?

You're doing a new container/row for each result from the query. Shouldn't you be using a single container/row and then a new card for each result?

Why do you need to change the upload directory? upload_tmp_dir being "no value" only means that it wasn't configured in the php.ini and so PHP will use the system's default temporary directory for storing uploads.

You're caring a lot about something that doesn't matter. If you want to avoid work, such as learning for yourself, then try not using quotes ever. Eventually you'll find a case where not using quotes was wrong. Then you'll know.

Except for the occasional time when you "have" to use quotes, such as with font-family names that contain spaces (like "Comic Sans") or with url()s that contain unusual characters (especially parentheses), most people don't use them. Definitely not for numeric values, like 100% or 15px. That's weird.

Nicer than storing generated PDFs on your server is generating them at the time they're needed. Because, at least in the case of invoices, the data supporting its contents shouldn't ever change.

That's ridiculous. Fight it. By adding an event listener for the quantity textbox's "input" event (when someone changes the value), doing the math, and updating the table cell. There are other HTML markup changes I would recommend to assist with that, but we're not at that point yet.

You've told us that it does not do what you want it to do but you haven't told us what it does do. What do you expect to see happen? What do you actually see happen? What have you tried so far to debug this?

With vertical-align.

With PHP? Yes, but not in a good way. Javascript is the answer. Why do you want to avoid it?

File paths and URLs are not always the same thing. Look at your browser's address bar right now: does it say? https://forums.phpfreaks.com/var/www/forums.phpfreaks.com/index.php?controller=idontknow&action=something&whateverelse&id=313889&name=altering-percieved-resource-path If your $root is also the root of the website then there's a really easy way to get an absolute path: start with a slash. That's it. / in the URL will correspond to the $root. <link rel="stylesheet" type="text/css" href="/css/actors.css"> <link rel="stylesheet" type="text/css" href="/css/gallery.css">

A few different ways of solving this, and the ones I like involve continuing with the food[x][y] names but making sure to give every "x" position a value. Because "food[][y]" is very much not going to work. Consider this markup: <input type="hidden" name="row[1]" value="1"> <input type="text" name="fruit[1][name]" value="Apple"> <input type="number" name="fruit[1][qty]" value="1" min="0"> <input type="hidden" name="row[2]" value="2"> <input type="text" name="fruit[2][name]" value="Orange"> <input type="number" name="fruit[2][qty]" value="3" min="0"> <input type="hidden" name="row[kljdshglkjsdfg]" value=""> <input type="text" name="fruit[kljdshglkjsdfg][name]" value="Banana"> <input type="number" name="fruit[kljdshglkjsdfg][qty]" value="6" min="0"> row[x] tells you what the existing ID number is. The "x" could be anything, but the ID number itself is convenient (even if redundant). Then the fruit[x][y] data belongs to that row in the table. If row[x] is empty then it does not exist yet. The "x" can still be anything, even though it doesn't exist, but picking a value anyway means you can group the fruit data by that key. If those additional fields are generated by Javascript then you provide an "x" with any random value. Such as literally a random value. Or a non-random but unique value like the current timestamp, though you would have to get at least millisecond precision to make sure there aren't duplicates if I want multiple rows added in the same second. The only gotcha with the arbitrary "x" is that you have to be careful with numbers because of how PHP manages array keys: if you picked the current timestamp with milliseconds, two rows in quick succession might be x=1234567890.123 and x=1234567890.456, but PHP will take both of those numbers and truncate them to integers, resulting in losing the first row's data because the second overwrote it.

You have a problem with file paths and somehow making one file appear to be in another place is the opposite of a solution. Consider that someday you, or maybe someone else, would look at that code and wonder how the hell it seems to be including the correct file when the file path is clearly wrong. 1. If you need to move the file then that sucks. Move the file and get it over with. IDEs can often help with rename operations, otherwise it's real simple to do a quick global search for "page.php" and update the paths you find; unless you have hundreds of files, that should take only a minute or two. 2. If you do have a lot of references to change then that hints at an underlying problem in how you use files for reusable code. Give it a few minutes of thought to see if maybe there is a better way of arranging your code or whatever so that it's accessible in a way that makes more sense. 3. Don't use relative paths. Use an absolute path based on the DOCUMENT_ROOT, as in include $_SERVER["DOCUMENT_ROOT"] . "/pages/page.php";

How much troubleshooting have you done on your own? Is the method producing the correct return value/response? Is the AJAX request working as expected? Is the Javascript producing errors?

Unfortunately you cut off the screenshot of those error messages just when they were getting to the good parts. Something is including header.php a second time, after the first time when marina.php included it. Fix whatever logic error caused you to decide you had to include it a second time. Then switch to require() instead of include(),

If you're having problems with some code then you should probably post the code.

Fixing values like that in code is not the answer. Where is that "HP OfficeJet Pro:9015e" value coming from in the first place? Why is it not the "HP9015e" value that you actually want?

If the date is being printed on the page by your own stuff then you fix that. If you're talking about a date that in the header that the browser adds on its own then you tell the user to change their computer's date and time localization settings to be in the format they want.

Your thread for choosing an editor might not have been the best place to ask for help with some code you've written, don't you think? Now that we're over here, // check if name only contains letters and whitespace if(preg_match('/^\d{21}$/',$TicketNumber)){ 1. That line of code does not check a "name" value, nor does it check if the whatever-value contains letters or whitespace. Letting code comments get out of date with the code they're describing is a great way to confuse yourself and other people. 2. That regular expression only allows for exactly 21 numbers. If you want to allow or require hyphens then you'll have to write something else. So what do you want to do? Require the hyphens? Make them optional? If they're optional, would it be valid for me to enter 1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0-1? What about 12345678901234567890-----------------------------------1? Come up with requirements for this number. Be as precise and explicit as you can be - because the code will reflect that.

Is the content of each post dynamic? Are posts for past events supposed to remain viewable?

What are these "functions" supposed to do?

If it can't connect then apparently define('PHPMAILERHOST', 'localhost'); define('PHPMAILERPORT',2500); define('PHPMAILER_SECURE',false); those settings are wrong. Do you really have a mail server running on localhost? And it uses the unusual port 2500?

You seem really fixated on this "I have to create a stored procedure in my code" thing when you don't have to do that. According to the code you posted, which is a really important point to make so if the code you posted is not what you actually want to do then you need to say something right now (and I'm about 99% sure it is not what you want), DROP PROCEDURE IF EXISTS test1; DELIMITER || CREATE PROCEDURE test1(IN LastID INT(5)) BEGIN SELECT person.RecordID AS PersonID, organization.Name FROM person INNER JOIN organization ON person.lnk_organization = organization.RecordID LIMIT 10; SELECT person.RecordID AS PersonID, organization.Name, organization.City, organization.State, organization.Zip FROM person INNER JOIN organization ON person.lnk_organization = organization.RecordID LIMIT 25; END || DELIMITER ; I'll say again what I've said before: there is nothing in that query which means you have to create it in your PHP code at the point when you want to call it. There is no information in there that depends on something only the code knows. So do me a favor and try something, okay? Create your "test1" stored procedure manually and remove the stuff about creating it from your code. Now try calling it. You can supply whatever "LastID" parameter you feel like. SQL injection won't be a thing because "LastID' is typed as an integer and SQL injection isn't possible with an integer. Now, you say you want to do something with variable limits. Okay. Have you tried doing that? Because recent MySQL will just let you do that: make the two limit numbers be parameters and specify those variables in the LIMIT clauses. Worst case, your desired stored procedure does not match your posted stored procedure, and the desired stored procedure actually has some aspect that cannot be parameterized. I don't know what it would be. If that was the case then you still (probably) wouldn't create a stored procedure at runtime because that is tied to the answer of a particular question: would your code, the code that hypothetically creates this stored procedure, ever call it multiple times? I don't mean "yes, it would call the procedure every time the code runs". I mean once that procedure was created, would the code that is currently running want to use it multiple times, and would completely separate code anywhere else running shortly after that code also want to use it? I can't imagine why your answer would be anything other than "no", which means you don't need a stored procedure because you can just run those SELECT statements at the time you want them. There's absolutely zero reason to create a stored procedure if it's only going to be used once.