maxxd

Actually, looking at what I wrote I'm wrong in my type-hinting on the Statements class constructor - sorry about that. You'll want to pass just the DatabaseObject object and then call the getDatabaseObject method inside the Statements class. This will avoid my mistake and allow you to create multiple database connection classes that all use a common interface so you can use PDO, MySQLi, etc. as necessary.

Yes, using globals is frowned upon. The reason for this is the lack of any real accountability or pinpointing modification points - if the variable is global, it can be changed literally anywhere and this can lead to days of hunt and seek debugging. The current basic pattern is to either instantiate a concrete instance of the database object and pass it to the other objects that require a database connection or setting up a dependency injection pattern/system, but that's a whole extra level of difficulty. Extending a class is, for the most part, perfectly safe and fine. Now, the presiding opinion is to prefer composition over inheritance which means most modern advice you'll see and read is that you should - as stated above - either use dependency injection or pass an object into the constructor. There's more controversy in that most people apparently have an issue with singletons, but if you always need the same database connection you'll probably want a singleton object that you pass into the constructor methods of any class that needs it. You pass an object to a constructor method in a series of `new` statements. Any time you write, for instance: $db = new DatabaseObject(); you're calling the __construct() method of the DatabaseObject class. So, hopefully this'll help a bit: <?php class DatabaseObject{ private $pdo; public function __construct(){ $this->pdo = new PDO('connection_string', 'username', 'password'); $this->pdo->setAttribute(PDO::WHATEVER); } public function getDatabaseObject(){ return $this->pdo; } } class Statements{ private $pdo; public function __construct(DatabaseObject $dbo){ $this->pdo = $pdo; } } $pdo = new DatabaseObject(); $stmtnt = new Statements($pdo->getDatabaseObject()); A few additional things: You can't access a private variable from anywhere other than the class that defines that variable, even if you're in a child class - in that case you'll want to use protected. Also, in your Database class constructor, you're missing `$this->` on your first line. $this->pdo is a different thing than just $pdo within a class or object. Long story short, there's really no one "way" to do things - best practices adapt and change as we all learn and grow as programmers. Best bet is to do the research you're already doing, really take in and understand the information and opinions in that research, and apply that understanding to the problem you're trying to solve - but remember you (or worse, someone else) will always have to revisit the code you're currently writing later on. Don't make it harder on that person as much as you can.

There was a div around each image in your other (I assume) related thread. Put it back and do as Barand recommends - in fact, if you use the CSS setup I recommended you can just add this to the .block definition: display: flex; flex-direction: column;

WordPress is much more approachable than Joomla. As schwim points out there are thousands of themes and plugins to choose from that can get a site up and running quickly. There are downsides to WP - you'll have to do some exploration as the themes and plugins are of widely variant quality, and the codebase itself promotes some not-so-awesome practices. Also, the introduction of Gutenberg native full-site editing has added some complexity for developers as it's kind of a mish-mash of JS and php these days, but you can always install and activate the disable gutenberg plugin to work strictly in php and ignore all that.

You can host a WordPress site on your own server without issue. There are WP hosting services out there, but they're not necessary.

The variable names only matter to the table itself. If you open your replies table in MySQL Workbench, you'll see `id` and `reply_id`. There's no indication that `id` is actually a foreign key that contains a user id. That having been said, in order to keep things sane outside of your database schema, rename the columns in the SQL or php. For instance, something along these lines: SELECT posts.id AS post_id ,replies.id AS reply_id ,posts.user_id AS post_user_id ,replies.user_id AS reply_user_id ,replies.content, ,post_user.first_name AS post_user_first_name, ,reply_user.first_name AS reply_user_first_name FROM posts LEFT JOIN replies ON replies.post_id = posts.id LEFT JOIN users AS post_user ON posts.user_id = users.id LEFT JOIN users AS reply_user ON replies.user_id = users.id; Then in the returned record you'd use $return['post_id'], $return['reply_id'], $return['post_user_id'], $return['reply_user_id'], etc. So behind the scenes the data labeling makes sense according to the actual data when scoped to the datatype it describes, and in php the data labeling makes sense when scoped to its dataset. I hope that makes sense.

In that case, the problem is happening where $_GET is being assigned, not where it's being read. $_GET['post_id'] could be literally anything, it all depends on what the system assigns to that variable. Show us the code that builds the link that takes you to the reply page. From a different tact - your column names are confusing and misguided. `replies.reply_id` and `posts.post_id` should both simply be called `id`, and in both tables `id` should be `user_id`. That way all the fields more clearly and correctly reflect the data they concern. I have a sneaky suspicion this is actually the source of your problem, but won't know until we see the code requested above.

You'll need to build an inner div, place it in the middle, column. Set the inner div to grid and style from there. <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Testing Grid</title> <style> *{ margin: 0; padding: 0; } body{ display: flex; justify-content: center; align-content: center; background: teal; } .outer-container{ background: lightcoral; margin: 0 auto; display: grid; grid-template-columns: 100px 1fr 100px; gap: 10px; justify-items: center; align-items: center; } .inner-container{ background: yellow; grid-column: 2 / 3; display: grid; grid-template-columns: repeat(2, 50%); grid-template-rows: auto; gap: 20px; } .block{ background-color: blue; padding: 20px; } </style> </head> <body> <section class="outer-container"> <div class="inner-container"> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> <div class="block"><img src="http://fpoimg.com/300x250?text=Preview" alt=""></div> </div> </section> </body> </html> Pardon the eye-searing colors; I like to be able to see what I'm doing... Your mileage may vary with the widths you're using - I'm testing on a surface tablet so the screen is smaller.

Unless there's a specific business reason to keep it, yeah. Programmatically it won't make a difference assuming you update any queries that currently try to select it.

That's how I would set it up, yeah. The only other thing is I've seen using INT for price and storing all prices in the smallest unit of currency. I'm American (please don't judge me) and we use dollars and cents, so instead of 14.25 for a product save the data as 1425 then divide by 100 (100 cents per dollar). PHP and JavaScript can have some problems with floating-point calculations and rounding, especially when dividing or multiplying.

So there are many things that should be improved on here, but the answer to your question is that your original query either failed or didn't return any results. Tell us what the error actually is. Having said that, there are some obvious things to do. First, make sure error reporting is turned on on your development machine so you can see when something goes wrong. Secondly, stop putting variables directly into your queries and use prepared statements. Finally, these two queries can easily be combined into one to save you resources and time.

Not really sure what the purpose of productType is in this schema, but you're still attaching the price only to the product. If you fulfill an order in January, then raise the price on that product in March, when you run a historical report in August your accounting will be off. Track the price of the product at the time of the order in the orderItem table, then use that for all reporting.

As Barand pointed out, each order only allows one product as of now; you'll need an order details table that tracks order number, product number, and product quantity. I'd also recommend tracking product price in the order details table as well, as this can fluctuate over time and you'll want an accurate historical record. I'd also recommend putting things like shipping address, as well as contact email and phone in a separate member order details table because people move, or order things to be shipped to different locations, etc. but I'm not sure if that's a concern for your current needs so take it with a grain of salt.

I assume this is mysqli because insofar as I recall PDO doesn't have a `bind_result` method. Assuming I'm not off-base there, I'd recommend taking the plunge and switching to PDO if it's a possibility in your project - it's a much more fluent and easier to understand interface.

If you're copying phpmailer.php into a directory manually you're not using the correct thing (or it's not being used correctly). PHPMailer is installed via composer and very well documented.

Don't try to make the string yourself - javascript isn't actually expecting a string; it wants an encoded array or object. Given that, instead of concatenating a string and then finding a way to remove the final comma in order to return said string (let alone escaping and other things you'd need to deal with), make your life easier by building a simple PHP array in your while loop and then json_encode that array when you echo it. In javascript you can then JSON.parse() the returned value and use it.

Beyond requinix's advice, https://github.com/barryvdh/laravel-debugbar is a popular package that helps with Laravel development.

Highly recommend PHPMailer instead of native PHP mail(). It's much easier to use and offers robust debugging when you run into problems. I don't have direct experience (mostly because I haven't used native mail() in a long time) but PHPMailer is apparently more reliable as well.

I'm not sure how WP handles the oEmbeds any more, but I'd say try firing your hook later. The third parameter to add_filter is a priority - set it to like 100 or something high. It's possible that somehow what you're doing is interfering with however WP handles oEmbeds in the content.

If you're using webpack or a build process, you can uselet let jqueryui = require('jquery-ui'); That should give you access to the functionality through the jqueryui object.

It sounds like you want to sort by geographical distance when searching address but by post ID when other fields are searched? If so there are a couple options - either you're doing the WP_Query call manually (the global $gmw_query variable makes me think this is the case) at which point check the search parameters and update the ORDER BY clause there. Or, this is hooked into a generic WP query at which point you'll want to use the posts_orderby hook to see if the post in question is a search and modify the ORDER BY clause appropriately.

Hey y'all. I'm currently working on a project at work and it involves creating a package with assets. Laravel's ServiceProvider has the loadRoutesFrom() and loadViewsFrom() methods which are all well and good, but the only solution I can find in the documentation or code for syncing javascript, font, and style files from the package to the full Laravel install is to run the artisan publish command. This means I'd have to run the publish command every time I make a change which is clearly not a solution I'm excited about. My solution at the moment is to use a symlink from the compiled assets location in the package directory to the appropriate directories in the public webroot of the overriding install - all good and working except for one thing. When I use the mix() helper in my view to load the javascript files they can't be found [ie: <script src="{{ mix('packagename/js/main.js') }}"</script>] where packagename is the symlink; however, when I point directly to them it works perfectly [ie: <script src="packagename/js/mix.js"></script>]. The asset() helper function works just fine. My only concern with just linking directly is that now I can't use versioning in my mix build process, my tester has a computer that caches aggressively. TL;DR - has anyone come across a situation where Laravel's native mix() function can't traverse a symlink or is this something known in the php ecosystem that I've somehow never come across before?

Use php to set a variable containing the number of rows in the HTML. Then use JavaScript to get that variable, check it, and react accordingly. Don't mix the two like you've done - technically, it's kinda possible but as you're seeing now it's a complete pain.

If you're dealing with SVGs I highly recommend looking at GreenSock - it abstracts away a lot of the annoying crap you have to deal with when using SVGs and canvas.

No, backslash is an escape character. Note how every character after a backslash is red in your screencap - that means it's being interpreted as a command character (tbh I'm not sure that's the right term - it's being interpreted as something other than a simple character in a string). So where you have `\`, you should have `\\` - this will escape the second backslash and make the interpreter read it as a character in a string. So, basically "C:\Program Files\your\path\php.exe" becomes "C:\\Program Files\\your\\path\\php.exe"