Well, in larger websites, the upgrade to PDO can be done in smaller steps. The output of PDO ends up in the same $results type object. Therefore you can do it in sections. You would basically just use both MySQLi and PDO at the same time. Since PDO connections are simple to start, you can change over the old DB code step by step and the site will still work with both. But, as I said, that would be for a future time. For now, when you have time you can look over this site which covers PDO in depth. It will help when you do get to that step. PDO-the-right-way Just for future info…
Now for the META issues… I will explain the process not the code. I think that might help with your knowledge. I mean, learning the process will make you understand the code behind it. There are two ways to handle this process.
First, the overall need here is to switch the page to another one. You could use AJAX processes to load the current data after it is created, deleted or updated, but, it appears your needs are simple and therefore that is not needed. So, we will talk about just URL switching.
Version one is the way you currently are processing the pages. Here is a list of how that works.
1 Display a page of data from the database adjusting it to look good on the page.
2 Allow changes on the data using forms ( Add, delete, edit )
3 Update any changes made and store them into the database.
4 Create a META to add to the page that is displayed and write it out to HTML on the page
5 The page is rendered (which means is sent to the browser)
6 The browser loads the newly created code and displays the HTML you created
7 Lastly the META kicks in and the page is switched to a new page (the same page actually)
8 The new page loads the data again but does not use the META and therefore is done…
*** As you see, there is a lot going on in your simple one-page display. The real issue with this type of process is that you waste time building a page just to have it switch to a different page even if it is the same page it is a switch. This means that you build the page twice. That is a waste of time. Waste of server processing, etc. Let’s look at a slightly different way to process this.
Version two is almost the same way you currently are processing the pages. Here is how that works.
1 Display a page of data from the database adjusting it to look good on the page.
2 Allow changes on the data using forms ( Add, delete, edit )
3 Update any changes made and store them into the database.
4 The page is rendered (which means is sent to the browser)
5 The browser loads the newly created code and displays the HTML you created
6 The new page loads the data which may have been altered and therefore is done…
*** This version saves all the code dealing with the META which is not really needed. It also displays the new live data and is not an issue. Not META is put into the rendered page and the page is not need to be refreshed, so no URL change really.
Let’s recap some thoughts on this. Any database data manipulation page such as adding, deleting and altering is normally handled on one page. Other pages are not needed. And, the data drives the displays. Which means that you alter the display as needed based on the data used. The form on the page always just posts to itself. Usually using < form method=“POST” action="" > … No page is used in the action section. This makes it post to itself. You put PHP code at the top of the page to handle changes in the data. The displayed items would read from the database which would now contain any changes done in the forms. And, of course allow more options to be altered… But, no refreshes or URL changes are needed since everything is done on the one page. Updates are handled before you display data tables. The page is “refreshed” in a way whenever the user posts the page by making changes. I guess you could say the page is auto-refreshed since when posted, it updates then displays the latest current data.
Well, I may be explaining this too much, but you did show interest in learning. Hope this helps…