maxxd

Is the issue that it's showing too much content or that it's overflowing on the right edge?

Not to mention WP's get_option() function allows a default in it's signature so the entire convoluted second ternary isn't necessary. $coronavirus_notice_banner_color = (!empty($_POST['action']) && $_POST['action'] == 'save_coronavirus_notice_plugin') ? $coronavirus_notice_banner_color : esc_html(get_option('coronavirus_banner_color', '#cc0000')); Either way, did you recently update your version of PHP or is this a recent plugin addition to your site? The way it's set up isn't supported anymore - PHP used to do it's best to figure out import in nested ternary operations, but it doesn't now. It needs to be explicit by way of parenthesis.

OK, so when you went down to the basement your parents had previously said it was ok for you to drink soda. You weren't looking for - and at that point didn't want to drink any - soda but you decided (understandably) that you might want some later, so you brought it up. Cool. Problem is, between the time you brought the soda up from the basement and the time you decided you actually wanted to drink it, your parents decided you shouldn't have it. Check permissions every time you do something or expect bad things to happen. If someone logs in with certain rights and abilities, don't expect they'll log out before you change those rights and abilities.

OK, so unfortunately Carbon doesn't have a native formatter for that. So one way or another, I think you're going to have to touch all of your models as they all extend from Illuminate\Database\Eloquent\Model and if you override that base class you'll have to update all the use statements. That being the case, I'd look to either global scopes or accessors to handle your case.

According to the documentation, Laravel automatically casts the created_at and updated_at columns into Carbon instances. I don't know what 'solar history' means, but it's possible the hard work is already done and all you've got to do is format the field as desired.

What change are you trying to make on the created_at field?

Depending on what it is you're trying to do with the data, there are several ways to change a field. You can set up an accessor or mutator or use a query scope, for instance. Query scope sounds like what you're looking for, although should worse comes to worst you could just write a trait and use it on your model instances where needed.

Certainly not trying to be an ass, but if it's so old the support forums are defunct you can pretty much guarantee there are major issues with it. I'd have to bet the biggest problem you're running into is that PHP has moved on - php 5 will mostly work on a php 7.x environment, but I wouldn't bet the bank on it. If you value your time, change your CMS - there are a lot out there. WordPress is everywhere and simple to use, so there is a ton of documentation as well as an absolute boatload of themes and plugins. If you're being safe it's not quite plug-n-play, and I do recommend reading the reviews on any themes and plugins you may use, but it's a decent starting place if you just want a site up. With just over 160 articles, it shouldn't be too difficult to migrate (even manually). And at least you won't have to spend most of your time trying to duct tape defunct and deprecated code while simultaneously putting the entire server in harm's way by using dangerously out-of-date code.

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.