Leaderboard

You've posted a few pieces of code without any context to how they are used. That makes it really difficult for anyone but you to know what you're talking about. If clickedD.php is where the AJAX request with the dentist's name is sending its data then only clickedD.php has the dentist's name available to use. The AJAX happens after the page loads, so PHP cannot time travel and take the information from it and retroactively change what happened when it was first creating the page. Without knowing more about what you're doing, I would say that you "have to" use clickedD.php and AJAX to modify the page with whatever information you want - information which would have to be returned by clickedD.php itself. But I suspect there's an easier method to do what you want. No way for me to know what it is, but I do believe there is one.

1. The second argument to add_filter() is the name of a function WP should call when it wants to use whatever filter. The name of your function is "new_mail_from_name" and not "alphaequipment". 2. get_option() will want the name of the option it should get. An option name would be like "blogname". You very likely do not have an option named "alphaequipment.com". Have you tried using that add_filter + function code without making any changes to it?

Of course you can <style type='text/css'> .w3-vomit { background-color: #f8b9ce; color: #c4ff4d; } </style> <h1 class="w3-vomit w3-padding">Example heading</h1>

I personally don't use bootstrap, but I'm assuming it has grids? Anyways, I use grids and HTML for a two column format. A third column would be easy as well using CSS grids. Here's the two column form using grids: <main class="content"> <div class="container"> <?php foreach ($cms as $record) { ?> <article class="cms"> <img class="article_image" src="<?= htmlspecialchars($record['image_path']) ?>" <?= getimagesize($record['image_path'])[3] ?> alt="article image"> <h2><?= $record['heading'] ?></h2> <span class="author_style">Created by <?= $record['author'] ?> on <time datetime="<?= htmlspecialchars(CMS::styleTime($record['date_added'])) ?>"><?= htmlspecialchars(CMS::styleDate($record['date_added'])) ?></time> </span> <p><?= nl2br($record['content']) ?></p> </article> <?php } ?> </div> </main> Here's a small section of the CSS: /* Approximately the size of a 1248px large display monitor */ @supports (grid-area: auto) { @media screen and (min-width: 78em) { .site { display: grid; grid-template-columns: 1fr minmax(23.4em, 54.6em); grid-template-areas: "header header" "nav nav" "main main" "sidebar sidebar" "footer footer"; justify-content: center; width: 75em; margin: 0 auto; } .masthead { grid-area: header; background-image: url(../images/img-header-001pg.jpg); background-repeat: no-repeat; } .checkStyle { grid-area: main; font-size: 1.2em; } .sidebar { grid-area: sidebar; justify-content: center; } } // End of Screen Size } // End of Last Grid Area Using grids cuts down on the CSS as well as the HTML, plus CSS really should be in a separate file and not inline. I'm assuming it's your CSS, but I'm sure you can have CSS from bootstrap that is an external fire as well that you can change?

Your links would be in the form <a href='djams_rmc.php?branch=X'> where X is the id of the branch. Then, in your appintments page (djams_rmc.php), you get the required branch with $id = $_GET['branch']; $query = $db->prepare("SELECT whatever FROM appointment WHERE branch_id = ?"); $query->execute([ $id ]);

If someone decides to be funny and set $_GET['page'] to "-42" you don't end up with messed up calculations. Using max, any number <= 0 will get ignored and $page will get set to 1 instead. If you calculate your total page count you should do a min($totalPageCount, $page) as well so that $page doesn't get set to something larger than $totalPageCount.

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?

When I first started coding in PHP there was a person on here (I can't remember his name) that helped me out a lot. I was hung up on securing my code and spent all night writing a script that I thought was "secure" then the next day I posted it here. He replied back to me and the first thing he wrote was to throw that script in the trash. He went on to say people who write security code work in teams and test them out before they are introduced to the wild (internet). There is nothing wrong with prepared statement and unless you are a large corporation the speed of prepared statements is fast enough. Prepared statements are as secure as they possibly can be and nothing is 100 percent secure. So I totally disagree on the use of prepared statement.

In my experience this really isn't the case, again due to caching. I'm sure you know as well, that the main area of result set optimization is index coverage. One other thing to know about MySQL with InnoDB is that the data is stored as a "clustered index". In other words, the data is stored in primary key order, and whenever you read a row where it was retrieved through the use of the primary key, there is no index read cost, and you get the data for the entire row. This also perhaps helps explain the value of the result set cache, as MySQL can return data from Server memory pages, and will use a number of techniques to optimize the use of cache, rather than reading from disk. There is some overhead in parsing the queries, but it's less of a concern in MySQL than in other db's. I might not have explained this clearly, but again, in MySQL, sprocs are not pre-compiled because someone used one at some point. They get compiled for each connection, when requested. After that, the sproc will be reusable in compiled form, for the life of the connection, but as I stated previously, in a PHP application, your connections will be either frequently closed, or closed on every connection. The details of that, go into how PHP is being run, but in either case, new connections and re-compilation of sprocs will be frequent with MySQL. The more you have, the more memory will be required to store the compiled sprocs, so if you have a lot of sprocs and a lot of connections, that memory could be significant, but if this is an intranet environment where you don't have a hugh query volume or lots of concurrent requests, it's probably not reason for concern either. There is one mechanism that might be of interest in regards to the compilation of sprocs, which is to use a persistent connection: <?php $dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass, array( PDO::ATTR_PERSISTENT => true )); The PDO::ATTR_PERSISTENT => true setting will trigger, again depending on your web server configuration, a connection pool, if for example you are using php-fpm. As frequently as you can find information about it, you will also find people telling you not to use it, as it can cause issues like deadlocks, hung connections that lead to timeouts/500 errors in your application, etc, but again in an Intranet environment it might not be a problem. I have at times in my career made heavy use of sprocs, triggers and views, so I'm not predisposed not to use them, but in my substantial experience with using MySQL, it is rare that I've found they were needed. Typically, when I have used them, it was to insure some sort of programmatic locking/transaction that I wanted to be guaranteed. One example that comes to mind is an implementation of a homegrown sequence object with naming and business rules around the range boundaries of the sequence numbers. It's always good to remember things like triggers and sprocs often will cause serialization and reduce concurrency. The other thing about sprocs, is that you are only moving code around. And in the process of moving code to the db, you are adding complexity to your development environment, as you have to make your changes to the database, rather than in your frontend code, when coding/debugging. You aren't going to have less code.