PFMaBiSmAd

There will be a GMP section in the phpinfo output - gmp gmp support enabled MPIR version 2.5.1

You have to troubleshoot what your code is doing, before you can fix the problem. For that specific symptom, what does a 'view source' of the blank page in your browser show? Do you have php's error_reporting set to E_ALL and display_errors set to ON in your master php.ini on your development system so that all the php detected errors will be reported and displayed? Are you sure the database statements are running without producing any database errors (do you have error checking logic in your code to test if the statements are failing)? Are you sure your database query is matching any rows?

This is going to be all negative, but Is that really the code you are using? You are using three different methods of putting php variables into ONE string (direct, concatenation, and a sprintf parameter), you are escaping one of the values twice, and you cannot prevent sql injection in database, table, or column names by using a string escape function because they are not string data that's inside of single or double quotes in the query (and yes you can turn on a setting for your database engine that allows you to use double-quotes around database/table/column names, but its not normally turned on, nor are you using double-quotes around your database/table/column names in your code), so there's not anything you are preventing them from escaping from. The meaning of the term 'escaping data' means to prevent special characters in the data from allowing that data to 'break out' i.e escape from, the string it is in. You also should not have column names that are specific values, like AppleFruitProducts. That indicates a bad database design that is not normalized. Based on what your have posted, your table should have columns for outlet_id, product_id, and availability (which I suspect is probably a quantity.) The id in the product_id column would indicate that the row is for AppleFruitProducts.

As to deleting past information vs querying for information from the display start date through the next 30 days, you should keep past information for historical reasons. In real applications, data is rarely deleted.

You may in fact have a data structure (array/database table) someplace that defines the normal start/stop time slots, but this should be static information that only defines the display grid. You should only store rows in the actual booking database table that indicate when something is booked. All you need to do to display the result is to query for all the booked rows that match the day(s) you are trying to display, retrieve all those matching rows into an array, get the data structure that defines the start/stop time slot grid, iterate over that data structure and for any booked time that has a start/end time that falls in between or spans the start/end time of the current time slot you are trying to display, display the booked state.

https://bugs.php.net/bug.php?id=34625 ^^^ Assuming you are using a mysql database (lol, which I just reread your thread title and you are), this is not supported. You will need to use the fetchall() method and access the first and last element in the fetched array.

Stop creating threads for your question. Since it's possible that you started this thread before you were issued the warning about hijacking the previous thread and you didn't see the warning, I won't issue a second warning for double-posting. This thread will be merged with your existing thread for this question...

Those two options are only available when the result set has been setup with a scrollable cursor (assuming your database type/driver supports scrollable cursors). You would need to add the following as the 2nd parameter to the ->prepare() statement - array(PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL)

Start your own thread for your problem. Topic locked...

That implies that php's output_buffering might be turned on in your php.ini, which would discard any status or error messages being outputting on the page. You can check the output_buffering setting by using a phpinfo statement on a page. If output_buffering is turned on, you should turn it off because all it does it hide problems and waste computer resources and human time.

The $template variable likely contains the content of the template file for the page, so you could just post the contents of that file, it's likely the template file that you edited right before this error started, from line one up through line 24 where the error is being reported at.

Setting $_SESSION['loggedin']='true'; (with the quotes around true) is setting it to the string made of the the letters - t,r,u,and e. That does equate (a two == sign comparison) to a true value, but is not exactly doing what you think it is. Removed the single-quotes around the 'true'. You need an exit; statement after your header() redirect to prevent the remainder of the code on your 'protected' pages from running. You could have code after that point that is clearing the session variables and without the exit; to stop the remainder of the code on the page from running while the browser is requesting the new page in the redirect header() you are not actually protecting the page. Have you set the error_reporting/display_errors, like DavidAM suggested, as the first thing (immediately after the first <?php tag, before any other php statements), on all the pages involved in setting or testing these session variables? You should actually have those values set in your php.ini on your development system so that you don't need to remember to put them in for debugging purposes and remove them when you put your code onto a live server (you want to log php errors on a live server, not display them.) Is the output_buffering php.ini setting turned off (you can check using a phpinfo statement on page) and you are also not using any of the output buffering statements in your code? Because, output buffering hides any php error messages you output on a page if you are also using a header() redirect on that page. If your code was actually logging you in without using $_POST['username'] and $_POST['password'], then that does indicate that register_globals are on. If you have any php variable named $loggedin, $_GET['loggedin'], $_POST['loggedin'], $_COOKIE['loggedin'], or $_REQUEST['loggedin'] in your code, any value from those variables will also back set $_SESSION['loggedin'] and could be producing the result you are seeing (this also allows a hacker to set your $_SESSION variables because he can set any of those external variables to anything he wants.) If you do have register_globals set to ON (you can check using a phpinfo statement), you need to either turn them off or upgrade to the latest php 5.4+ version where register_globals have been completely removed.

The correct method is to only store content in your database using a template, where you have place holders in the template that get replaced with runtime values.

This is going to be all negative, but here's what's wrong with what you are trying to do - A) There's nothing that would prevent <?php from being saved by a query. Whatever problem you were having doing that needs to be solved. B) Databases are for storing data, not server-side code. C) The C in CMS stands for Content. Php server-side code is not Content. D) The method you would need to use to accomplish this comes with a Cautionary warning in the php documentation - So, if any user supplied content that is output on your cms also contains php code, that code would get executed.

The only line that's relevant in the 900+ lines you posted, which I have since removed from your post, is line 794 - eval("\$page=\"".$template."\";"); You would need to troubleshoot the php code that is in the $template variable, up to line 24, where the error is occurring. If you want us to help, that's the code you would need to post.

What evidence do you have that it's a memory issue? It's more likely that for the frequency of http requests and the processing being done for each request, that there's no processing time available for anything else. What sort of errors are there in the Apache error log?

For your specific usage, you should use a exit; statement after the header() redirect to stop execution of the remainder of the code on the page. You don't need to surround everything else (lol, no pun intended) on the page in an else {} statement.

There are about 200,000 php upload examples posted on the Internet. Start by examining some of them. Once you have successfully uploaded the file and checked for upload errors, you can use the uploaded file information in your email attachment.

You cannot split the syntax for any one statement between files. Any language statement that you open, must be closed in the same file. The main file is parsed, tokenized, and interpreted when the page is requested. Any induced code is parsed, tokenized, and interpreted when the include statement is executed.

Instead of initializing $_SESSION['step'] to a one, set it to 5 - if(empty($_SESSION['step'])){ $_SESSION['step']=5; // start at step 5 (was a 1) } You can then of course eliminate all the logic for steps 1-4 and even the switch/case statement logic and the check_step() function and logic to call it.

If you apply the troubleshooting methods to the original code, for the case where it doesn't allow you to adopt an egg, you will find what code is responsible for limiting the number. It's probably in the canadopt() function.

Because computers are not good at generating truly random numbers, the random number/loop method will have a problem when you have used a majority of the available numbers as it will take more and more passes through the loop (and database queries) before you find an unused number and you may reach a point where that method cannot find an unused number. To do what you are asking, you should generate all the possible numbers, in sequence, in an array, randomize them, then store them in a database table. Then you just get the first unused number and either mark it as being used or delete it.

It would be easy for a computer to cycle through all possible 7 digit numbers until it finds one that works. Why do you need an id that's so short and made up of a small set of characters?

You have several conditions in your logic that must be true before the INSERT query is executed. To pin down the problem, you must determine exactly at what point your code and data are doing what you expect and at what point they are not. Echo unique progress messages before and after conditional tests to determine what the execution path is. Use echo/print_r/var_dump statements to display what data values are.

Is there any white-space (tab, space) after the " and before the > ?