requinix

$q = 'SELECT ID FROM table'; That is a SQL query. You have to run that query through your database, receive the results, and then look for each single matching image in the directory for every returned record. You can probably skip looking in the directory, though. It will only tell you if the file exists. So if you already know (or assume) the file exists then you don't need to bother looking.

Okay. Fine. So don't track history. And now that you've made a decision I call tell you that I wouldn't store a history for this either. Stop caring about that file. I guess you missed the rather significant part of my post where I tried to explain what it is. Not sure what you're talking about but I'm 99% sure "loop while error is not present" is not the answer. sigh I'm done.

Don't worry about the IBD file. MySQL knows how to manage itself, you don't need to go second guessing it because of what you think you saw in Notepad. The question you think you're asking is whether to use an UPDATE or a DELETE+INSERT, but the question you're actually asking is how you should manage uploaded files that can be replaced. The answer to that is... well, it depends. There are two basic options: 1. Forget the previously uploaded file. You don't care about it. Take the new file and stick it wherever you want, update the database, and delete the old file. Gotta delete. Because if you forget about the old file then there's not much of a point to keeping the file itself around too. 2. Keep track of the previous file. You'd probably want a table that holds all the information for past and future uploads, and that's where you track them. For using those files, instead of storing the file information in whatever place, you reference the file in your upload information table. New image, new information row, and you update whatever place was affected. This lets you keep a history of everything, which probably isn't important for stuff like user avatars but is frighteningly important for stuff like monetary transactions. "Okay, I've decided that I want to do <whichever option>. But what about my literal question? Should I update or delete and insert?" Time to learn about an important concept in computing that disappointingly few programmers ever end up learning: atomicity. That's the noun version of "atomic", which means (in this case) that whatever operation you need to do can't be interrupted or broken in half or appear to anyone else as being anything less than one single action. Atomicity is important for stuff like files and databases because you basically never want to look at a file or data in the middle of some important operation. Imagine your site is popular. Really popular. Facebook or Twitter popular. Constant traffic to your servers. Now imagine a user uploads a new image. When the code is ready, it needs to go off into the database to make whatever changes it needs to make so the user has the new image. Say you go with DELETE and INSERT. Your code runs one query that DELETEs whatever, then another query that INSERTs. Sounds fine. Except remember how your site is always busy? It's quite possible someone was looking at your site at the moment in between those two queries. Since the DELETE has happened but not yet the INSERT, your code isn't going to find whatever data it needed to find and the user is going to get a bad experience. If that user was a CEO for a huge company that wanted to buy you out for lots of money, they might not do that now. A DELETE and INSERT is not atomic because there was that point in between the two queries. It was not "one single action". Instead you go with UPDATE. The database does whatever it does, but the clever people who wrote the software for it already knew about stuff like atomicity. And they made their system guarantee that UPDATEs are atomic. One single action. If you do an UPDATE when that rich CEO looks at your site, the database has guaranteed to you that either (a) the CEO will see the old data because the update hasn't happened yet, or (b) they'll see the new data because the update has happened. There is no moment in between old and new for stuff to be broken.

Look. Here's the deal: I don't know your business or application. Not like you. All I can do is offer general advice and what-ifs, and there's no way for you to explain everything to a degree where I'd be comfortable going beyond that. So what you need to do is take what I'm saying under consideration, think about how your business works, think about how your application is written, and decide for yourself. Will it make sense to people to go to your general online store to buy subscriptions? Will it be a hassle to support a subscription product? You need to figure out the answers to those kinds of questions, then act accordingly.

So far my vote would be for keeping subscriptions separate from everything else, but on the pages for products that the subscription covers (podcasts?) you can advertise the subscription model. Or during the checkout process, try to upsell them into the subscription funnel instead.

We will not write the code for you. Try to understand what I wrote in my reply and amend your code. If you have more problems when you are done then we can help you fix it.

Yes. You can certainly tell people about the subscriptions, anywhere you want, but unless you're prepared to make changes to your store and product models, it's easier to keep it all separate. Yes. It isn't impossible to add subscriptions to the store, but are you sure people will be looking at your online store for a subscription? If you advertise the store as a place to buy goods then they might not think it's the same place to buy access to the website. If it features prominently as a purchase place, maybe they would. You could also not offer the subscription as a "product" but as something they opt into. You can keep the details of the subscription as a sort of hidden product that they cannot add to their cart - only your PHP code can do it, which it would when the user goes through your subscription page thing. Treating the subscription as a product means you have to add a concept of conflicting products to your store. That might be useful for other things, I don't know, but if not then you're creating a lot more complexity for only one thing.

fopen() gives you a "resource" for you to read from and write to the file. "a" means to open the file in append mode, putting you at the end of the file and only allowing you to write. If you want to read and write then use "a+" mode and fseek to the beginning. You can read each line with fgets to look for repetition. You need to use a variable to remember whether you have found the repetition. Start the variable as false, then if you find the repetition set it to true. After the loop, if you did not find the repetition then you can fwrite() the new line (which PHP will put at the end of the file). Remember to fclose at the end.

No, but I don't think you should include subscriptions in the store. A subscription is access to the site or whatever. The online store is for products. They are not the same thing.

Unless the error message is wrong, it thinks somewhere in your table is the string "`test`.`download`.`ADDRESS`".

You started up php through gdb but then killed it with a ^C. The backtrace is what it is because you killed it. If running concrete5 is what crashes then you have to run that. As in gdb `/usr/bin/php72` and then run ./vendor/bin/concrete5 c5:install -i (or whatever).

Try it and find out. In the hour+ since you posted this thread, you could have installed MySQL Workbench, set it up, and started using it.

And all the other on*s, yes. The reasons to avoid them are too complicated and lengthy for me to want to go into now (Google is your friend), but the highlights are: 1. It's a good thing to keep HTML and Javascript separate from each other 2. Using onclick attributes means you can only have the one click event handler 3. Managing event handlers that way is annoying when you start getting into larger applications Establish the right habits now and you won't have to reconsider what you're doing later.

if( isset ( $action ) && $action == 'get_production_history' ) { Where is $action being defined? If it's coming from $_GET/POST then that is where the isset() should be. Because the point of using it is to make sure it really does exist (or else PHP will complain that it does not). But once you've assigned something to a variable, it definitely does exist (even if the thing you were assigning to it did not), so the isset() is probably unnecessary. foreach ( $dept_codes as $d ) { //loop through returned db rows foreach ( get_production_history( $order_id, $pdo ) as $row ) { get_production_history() does a database query, right? Given that you aren't passing it any department information, won't this run the exact same query over and over again? If that is the case then you should switch these two foreachs around so that the database one only happens once while the department one (which just goes over a small array) happens more than once. if( $row['dept_code'] == $d ) { If you only care about production history data matching a specific department then running a query for everything is highly wasteful. This problem partly goes away if you do the thing I said above, but better would be to find a way to run a modified query for production data that only includes results for the departments you want. if ( !in_array ( $row[ 'id' ], $production_history[ $d ]) && $row[ 'status_id' ] === 1 ) { Does this mean that the query will somehow be returning multiple rows with the same ID and dept_code for status_id=1? That doesn't sound good. } elseif ( $row[ 'status_id' ] === 3 ) { How do you know that this $row corresponds to the earlier $last_recorded row? Wouldn't it just be easier to forget $last_recorded and use $row's ID in here? foreach ( $dept_codes as $d ) {... foreach ( get_production_history( $order_id, $pdo ) as $row ) {... // assuming you rearrange these two loops like I said foreach ( $dept_codes as $d ) {.... foreach ( $production_history as $dept => $value )... foreach ($value as $k => $v)... foreach ( $production_history as $dept => $value )... foreach ( $production_history as $dept => $value ) {... foreach ($value as $k => $v) {... That's a lot of loops over the same data. You should be able to combine some of these. Tip: use a continue to skip the rest of the code in a looped block. header('Content-type: text/javascript'); text/javascript means Javascript, and while you are outputting valid Javascript, that's not what you're trying to do. JSON is "application/json".

1. It's bad practice to create global variables. 2. It's also bad practice to write inline event handlers. 3. Your message says "at least 5" but your code checks for more than five. <textarea id="something"></textarea> <script> (function() { var character_count = 5; var multiples = 1; var textarea = document.getElementById("something"); textarea.addEventListener("input", function() { if (textarea.value.length >= (character_count * multiples)) { alert("At least 5 more characters were entered."); multiples++; } }); })(); </script> 1. Wrapping all your stuff in an anonymous function that executes immediately will keep the variables safe. 2. Use addEventListener to attach events dynamically.

Every time this function runs, incrmt - which you really should spell out normally - will be set to 5. Every time. The variable needs to come from outside the function so there's only one copy of it floating around.

Your terminology is incorrect (an "argument" is something passed to a function when it's called) but yes: the function returns a new value which array_map uses in the new array it's creating.

Just about everyone will recognize what you're describing with that name, but they're officially called "closures" or "anonymous functions". It's a function like any other. It takes an argument of $number and returns something. There's nothing particularly special about how it works. The & indicates a reference. array_walk has a special behavior where you can modify the value in the array - but instead of returning the new value, you mark the first argument in your function as being by-reference and modify it directly.

People still use StackOverflow? That's only half a joke. Their community has always been toxic to newcomers and there's so much emphasis on correctness that anything less than perfect is unacceptable. And there's the hostility towards any form of discussion about what is right that I always mention when this subject comes up. SO is good when you're looking for a precise answer to a specific question, but it's terrible for actually asking the questions, or trying to weigh in as a new person with different answers. But I am glad they dethroned Expert Sex Change in search results. edit: If Your Common Sense/shrapnelcol came across this thread and decided they wanted to join our forum...

What you need to do is go back to that SUM/COUNT thing you tried. Because that is, in fact, the right way to go here. Probably. What was that query and what do you mean by "it didn't work"?

Now there's an avatar I haven't seen in a while. Conditions in an ON are about deciding how stuff in the two tables relate to each other, while conditions in the WHERE are about filtering what you want to see in the results. That's probably not the best way to explain it... Here you're dealing with readlog.uid. Normally stuff in an ON is for fields in both tables that equal each other, but remember: it's about relationships here. And what that uid really means to the query is "chapters that are not in someone's readlog". In effect, checking the uid is half of the work (the "someone's readlog" part) and the OUTER JOIN + dateread is the other half (the "chapters that are not in" part). Of course, the fact that the second half is being done in outside an ON and actually inside a WHERE is just an unfortunate result of the SQL syntax... Ah, I'm tired. That probably didn't make any sense and I'm sure someone else could do better.

What? The code you posted will take sample.txt, read what's in it, add to that another copy of what's in it but with the regex run on it, then dump that all back to sample.txt. So if you run the code multiple times then the files goes like a -> ab -> abbb -> abbbbbbb -> abbbbbbbbbbbbbbb...

If you tried increasing the memory limit and the memory limit didn't increase then you didn't increase the memory limit. You did you edit the correct file? Restart PHP or your web server?

You might as well do it for all your classes, not just this "libraries" folder. As an example of how to do autoloading, I would point you to the place in your code where you are (apparently) already doing autoloading.

You can make whatever changes you'd like - as long as that User.php file gets included before you try to use the class. Or better yet, learn about and implementing autoloading so you never have to care about including files manually.