maxxd

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?

No idea what your css looks like, but the second snippet is a form within a form, and all the fields are inside the inner form. Depending on how your element selectors are set up, that could cause a problem. Either way, if I'm not mistaken it'll almost certainly effect your form function.

OK, so places to start researching in order to understand Barand's reply: https://www.php.net/manual/en/book.pdo.php https://www.php.net/manual/en/ref.pdo-mysql.php https://www.lifewire.com/database-normalization-basics-1019735 Full disclosure, I've not read the final link fully but from what I've scanned it looks decent. Your data structure looks simple enough right now, just know that as it grows the need for normalization will grow.

Problem is, you're talking about very different ways of getting the data. In the grand scheme of things the problem is as easy as ginerjm says - you get the data and output it while building the response. However, if you're using a CSV you'll need to research fopen() and fgetcsv(). If you're using a JSON string it'll be fopen() and decode_json(). If it's a database, research PDO and MySQL. And if it's an Excel file, that's a whole other can of worms that's going to entail third-party libraries. Each potential path has it's own ups and downs; you'll need to decide how you want to store and retrieve the data. Outputting said data is easy - in every case it's a simple echo statement.

Float's a but quaint these days, but I can't recall off the top of my head any major updates in browser interpretation of it recently. I also don't recall hearing of anything removed from browser parsing of older standards. Sorry for the not terribly useful post, but unless there's some browser-prefixed or experimental definitions or functions I can't think of anything in the past year or so that would break CSS backwards compatibility. Maybe somebody else remembers something?

OK, looking closer you've got more problems than just not using the correct definition. Your HTML is invalid - your h2 elements are I think supposed to be class title2 and aa or bb, but right now that's two separate string so "title2" is ignored entirely. Your CSS is repetitive and nested incorrectly - if you look at the blocks you've marked as making the text glow, they're all wrong. The first block will only target a div or span with a class of 'aa' inside and H1 element, the second will only target a div or span classed 'bb' inside an H2 element, and the third a div or span classed 'cc' inside an H3 element. So none of your markup matches those selectors. Get rid of the H1, H2, and H3 and define .aa, .bb, and .cc. Or, better yet, just define a 'glow' block and use that class on every text block you want to be styled that way. The .title1, .title2, and .title3 classes have nothing to do with the effect you're trying to achieve so remove that comment and stop confusing yourself. There's also at least one typo in your CSS that your IDE should warn you about.