maxxd

garyed - honestly, it's not as bad as it could be. I first read your post and assumed you were still using the mysql_* functions, at which point you'd be kinda hosed. From your posted error messages, it seems like that's not the case so that's awesome. As requinix said, you're gonna have to just work through it - the nice thing is it doesn't sound like you'll have to completely rewrite most if not all of your code. There were several things that moved up from notice between 7.4 and 8.0; it's just going to be a case of finding those and making sure they don't throw errors.

PHP won't interpolate variables inside single quotes, so your search string was literally %$str% in the first example. Inside double quotes, however, PHP will replace the variable with the value it contains.

It looks like that'll do what you're looking for, though obviously I've not tested it.

If you follow requinix's advice and make the constructor private in the first code sample it's a textbook example of the Singleton pattern. While there was a period a few years ago that people railed against using Singletons, the furor seems to have died down recently. In my experience, 90 percent of the time it's perfect for things like setting up database connections.

In your function ecommercehints_confirm_email_field_validation() (yeesh, wordpress really promotes bad ides...), your second if() statement needs to be an elseif() branch. The reason is that in the first if() you're checking to make sure $_POST['confirm_email'] is set, which is correct. In the second, however, you're assuming it is set by trying to compare it to another value. So if you make it an elseif branch it'll only run when the variable is set, which is the behavior you want.

Not gonna lie, I'm kinda missing the restrictions on the permission policy so I'll just trust that it's necessary to structure that way. As to the primary key/foreign key part - just for me - unless I know it's going to be a one-to-one relationship forever I'll assume it's going to turn into a many-to-many at some point. It's probably just my innate desire/tendency to over-engineer so, so many things, but I have gotten to a point where it's no harder to reason about than a simple one-to-one link. It's just me and YMMV, but I personally have never found it harder to code on a one-to-one with an intermediary table than it is to refactor a one-to-one relationship into any other relationship type.

OK, so I'm looking through this again and while I still think I'd start at your option 1, I have a couple questions about your reasons for questioning that approach. Why do you need a PermissionPolicy to be referenced by only 1 project or asset? Seems to me that permissions would span projects and assets at least, unless there's a very specific set of business logic that dictates this. I have to admit I can't imagine what that would be, but I'm not a business person, so... Is this a concern? If there's a possibility of needing a "many-to-one" relationship, IMO (obviously) there's no need to think about a one-to-one and it's probably better to consider the possibility of a many-to-many relationship just in terms of future-proofing. It doesn't add that much cognitive load to have a linking table even if it may not be strictly necessary at the time, but it gives teams the possibility of expanding scope without too much ... well, cussing to be honest.

Both answers are correct and need to be fixed. First, @requinix's answer is absolutely correct, but as @ginerjm pointed out, you've also named your field 'my_select' while you're checking $_POST for 'myselect'. Set the value of your blank option to -1 and check if $_POST['my_select'] >= 0.

The first schema is probably where I'd start looking at it, although it may be worth it to add a linking table between the members and permissions policies tables. But honestly that's going to have to be dictated by the current business logic for the project.

I worked with a system for a while that used AWS SQS to feed tasks and data into smaller php functions (microservice-style) that were long-polling for changes in the queue. Offloads all the data processing to a completely different thread (or server in some instances). However, one major drawback is that it can be difficult to reason about and document once you get more than two or three "microservices" handing the processing.

Neither the mysqli_* nor pdo_* functions are a direct replacement for mysql_*. You're going to have to rewrite code. Advice you didn't ask for; go with PDO. It's much easier to deal with than the MySQLi functions.

<form method="post" action="<?php echo htmlentities($_SERVER['PHP_SELF']); ?>"> // The first form - this works perfectly <input type="submit" name="submit" value="Select"></span></b></p> <input type="hidden" name="userid" value="<? echo $userid ?>"> </form> There's no field named 'type' here (actually, there's no field named 'type' anywhere in the code you've supplied). So, $_POST['type'] can never be "UG" and this conditional: if ($type == "UG") { will always fail. So your first block of code won't run, which is apparently exactly what you're seeing.

While I wholeheartedly agree the way to go is to save out a CSV and let somebody open it with Excel, if you absolutely have to deliver a native Excel file, there are a few libraries available. This one seems to be the most used/respected in my Googling.

Yeah, at this point I don't think there's enough concrete information to give advice. Given what you've described, I'm not sure I can come up with a change that would bork the whole system less than it would using a different pattern. Also, as I understand it using an abstract class is not quite the same as inheritance - it's more akin to using an interface with some pre-baked methods. While this can be problematic for the same reasons as concrete inheritance, it can also imply an interface for an API. From my reading, folks in general seem less adamant against extending an abstract class than a concrete one. Either way, as much as you're able without talking out of turn job-wise, what exactly is the situation?

Yeah, there are still I think kind of a ton questions here. Inheritance could potentially serve the purpose in this case (see Laravel controllers, models, etc. for example) but maybe you'd be better off with a prototype or adapter pattern? Or, assuming I'm not reading the question wrong, maybe an interface; that way you'd have known methods with dynamic implementations.

I haven't not used PHPMailer in quite some time (it really is worth checking with your provider - if they say no, get a new provider) but perhaps if you comment out the Content-Type set under the comment //plain text in the attachment branch of your if/else it won't reset the content-type from text/html to text/plain as it's being asked to do. Specifically, this line: $body .= "Content-Type: text/plain; charset=ISO-8859-1\r\n"; It may do nothing as it's assigned to the body instead of the headers, but it's the only place that specifically assigns the content-type to plaintext, and it only happens when there's an attachment so it sounds like it's a good place to start.

I agree that especially at this point in learning OOP, don't concern yourself with "compactness" at all. This may be personal experience but in my career most of the 'compact' code I've come across is just entirely too clever. You can (it was easier prior to [I think] 8.1) nest ternary statements to such an extent that a complex if...elseif...else construct is on a single line. Compact? Absolutely. Readable? Not even slightly. I'd even go so far as to say right now be overly verbose. Make absolutely sure you'll be able to follow not only your logic, but your thought process when you come back to this code in a few weeks. Document everything. The business logic of your app will be easy to forget in a week, and if you're cutting corners trying to write "compact" code you'll have no idea what the heck you were doing with a section of code, let alone why you were doing it. After you get a good grip on OOP principles and how best to apply them to PHP, start thinking about conciseness of code; don't worry about how many lines it's taking, worry about how comfortable it is. Documentation is important, but there are certain situations where is slows down the reading and understanding of the code; in much the same way being too basic with the code and it's structure can slow reading and understanding almost as much as being too clever. It's at this point that you'll recognize certain patterns and constructs that you won't necessarily need to document and that are generally readable. Just work on writing exactly the amount of code and documentation that needs to be written so you or someone else can pick the project back up in six months and not want to cry. You'll learn the middle ground that makes the code readable and maintainable (insomuch as you can - nobody's perfect and deadlines just ... well, suck).

It's not a private repository and the composer.json file you've posted doesn't define any additional repository sources, so I'm not really sure why it's throwing that error at you to be honest.

You're saying that carlos-meneses/laravel-mpdf is timing out? Maybe it was a glitch with packagist - it's doing fine here. There's only two additional packages it looks like. Now that you've removed it from the composer.json file, have you tried manually requiring it with `composer require carlos-meneses/laravel-mpdf`?

It's a path type repository. You can also set up a github repository as a composer source, which may actually be what the OP is discussing.

mekodak - I'm assuming what you're referring to as 'state' is the value in the 'online' property. So, once you ingest the JSON return and parse the data, loop through the resulting array and print the 'online' index. The third record 'name' value looks weird, but potentially not incorrect. morocco-iceberg, use the code button (<>) in the post editor toolbar.

Do you not keep historical data? If not, how do you track and/or display past rounds, settle any disputes over past rounds that may arise, or make decisions about the future architecture based on past demand and performance? I may be misunderstanding what you're saying but if I'm not it sounds to me like cutting off your nose to spite your face, hence my comment about the smell.

I'm curious as to why you have to drop a table and recreate it after each round. Explain that, please - it smells off.

Famous last words... 😆

What does the JavaScript function myFunction() look like?