requinix

These things are normally done best by sorting an internal data table. There's a fair bit I could say so how about an example instead?

We try not to delete accounts, especially if they've made any posts - even if they were back in 2007. Here is where I would normally talk about stuff like changing the email address on file, but if you're cleaning up all that anyways then it probably doesn't matter. So then I would follow up with saying that you can just, you know, not use the account anymore... It's not like having it on the books is a bother for us.

You want a count of transaction_ids that only have one row each? One inner query that lists all the transaction_ids with one row, then an outer query to count the number of rows inside. To delete, think about what you could do with that same subquery and an IN. Ah, but it's restricted to cases where there's only one row per transaction_id. No ambiguity so it works out.

1. You took a step backwards with the document.ready. You should not use an onclick with the <button>, so take that back off. Instead you'll use code for it. For the Javascript side, the first line should be just "$(function() {" - using document and .ready is a longer form that you don't actually need to do. No add_to_translog at all. 2. You swapped add_to_basket_submit with main-product-button, but that wasn't the problem. The data you are sending to the PHP script is the data:{action} you have in the Javascript code. Nothing else. Not even the button you clicked. Except your PHP code expects there to be more. If you want to test that the data was submitted then either the use "action" that is in the data being passed, or check that the $_SERVER["REQUEST_METHOD"] is POST. 3. Prepared statements are very important. It's about security and making sure people can't destroy your database. So make sure you take care of it. 4. Now the script is just doing some output without trying to redirect. Keep in mind that AJAX doesn't know whether "Records added" is a good thing or a bad thing. As it is, AJAX is going to think the call worked and you'll get the Hooray message either way. It's possible to indicate to AJAX whether it was good or bad, but for now you can simply use the "response" in the .done callback - like log that message to the console.

You're on the right track. 1. Messed up the syntax with the $(document).ready stuff. Take another look. 2. There is no "add_to_basket_submit" anywhere in what you're submitting so that check in your code won't work. 3. Never put $_POST values directly into a query. Look at mysqli's prepared statements. 4. The script is being called through AJAX so there's no point trying to make it redirect anywhere.

You would change the Javascript so that it does the .click using the right selector (where you have the ID now). If that's where the AJAX is going then yes, that is where you would need to put the code to do whatever it needs to do.

Depends. Do you have multiple buttons? You can't use the same ID for all of them, of course, so you would be forced into something else (like classes). You know you aren't sending any actual data through AJAX yet, right? You kinda need to do that. Probably? We don't know your application. If you have a question about your code then you're in the best position to find the answer.

It really should be a button, like a <button> or an old-school <input type=button>. It doesn't have to be a submit since you're using AJAX, but if you could if you wanted to (just make sure to cancel the submit event inside your handler). The event handler can know which element triggered the event. What's that code?

Well, if you're triggering the AJAX then you must be able to know which button was clicked, right? So... pass that information along in the request. Maybe posting code would help explain where the difficulty is?

You've never used MySQL from the command line? How about phpMyAdmin? How are you writing these queries if you don't have a way to test that they work?

Not technically what I asked but okay. How about the other question?

Sounds like your query didn't return anything. Does the uname have the value you think it does? Have you tried running the query manually?

Even if that didn't fix it, you still need to do it. fetchAll() will fetch all of the results. If you just want one row then you need to use a different method.

lol tru

Speaking of infallible, I accidentally left off a 't' from "I just means".

https://www.google.com/search?q=tomtom+add+country

Hey now, being an admin doesn't mean I'm infallible. I just means I have the keys to the kingdom. I'm a normal PHP developer like just about everyone else here. I suggest avoiding Zend because it's over-engineered, and that makes it complicated and bloated. The PHP industry has moved towards simpler frameworks that don't try to do everything you need out of the box. Routing, MVC, and database abstraction are the main focus, and the rest is about providing a foundation to build the application from.

The form data will be available in the $_POST array according to the input name. For example, the time requirement will be $_POST["answer"]. Try using that. Does it work? If it does, try again.

A framework will help you, but don't choose Zend. Try Laravel or Symfony or one of the many others that are better.

So does that mean each Request is for a single Query? It sounded like a Request could have one or more Queries. I think... that I would do the second option. Both solutions need a store for the ArchiveQueries that can be searched, and presumably one specialized for finding them, which means the most significant different between the solutions is that one needs an SplObjectStorage and the other does not. Reducing complexity would be good.

CentOS 7 doesn't have PHP 5.6. It's still on PHP 5.4. Whatever source you used to upgrade PHP apparently doesn't include imagick. You'll need another place that does.

Don't worry, I understood the request thing. I was thinking along the lines of wanting to execute queries either (a) in the order they arrive in, as in request #1's queries should probably begin being executed before request #2's if that's not done concurrently, or (b) according to an undescribed priority system, like where one client/request may have a higher priority than another based on something, or that certain queries are innately more important than others. The required order thing turns out to be relevant. I was suspecting you wanted first-in-first-out, but apparently that's not quite the case. The data structure I first had in mind was a queue (ie, an array). Push query/request pairs into it when they come in, pop them out when you need to execute the next one. You would execute the query and notify the "request" of the result. AFAIK it's not part of SplObjectStorage's spec to maintain item insertion order so that wouldn't be appropriate. However maybe you need to arrange queries not just by FIFO but some weighted combination of FIFO and query complexity. That suggests a priority queue (SplPriorityQueue), where it's mostly a queue except higher-priority items go to the front of the line, with the added wrinkle of needing to support dependencies. So I'll stop my reply there with more questions: 1. When one of those "certain types of requests" comes in, how are the queries and the subtraction managed? Does the request actually say to do a couple queries and a subtraction, or does it say to do one query and the system recognizes that as meaning multiple queries and some processing? 2. Any particular reason the easy queries need to come first? Get too many and they'll crowd out the complicated ones. Surely the fairest treatment would be to execute them more-or-less as they come in? 3. Say a request for query A minus query B comes in. Are queries A and/or B reasonable queries to run on their own? Could another request come in just for query A, and those results be used for the subtraction? 4. You've mentioned reusing existing queries. Does that imply caching? Or is it really a question of coincidence where multiple requests just happen to arrive in the same short time frame and involving some of the same queries? Off-topic, but $app->get(_VER_.'/bigQuery', don't use the API version number like that. If you change the VER then this code will no longer work for the previous version but instead will suddenly work for the new version. API versioning needs to provide backwards compatibility. If you want to support versioning well, either (a) Send (HTTP) requests through a versioning layer first, which identifies the version number and endpoint and routes the request to the proper handler. New revisions to the API come with updates to the version layer. This is a bit complicated and probably not good to use here. (b) An easier variation is to program endpoints into this versioning layer, as in something like $versioning->get(1, 'bigQuery', function...), then have it populate $app. It would know the highest version number and automatically fill in the gaps between versions. I can explain this in more detail - in fact I could just write the whole thing out. (c) Hardcode the version number for each endpoint. New revisions to the API entail copy/pasting the unchanged endpoints with the incremented version number. Duplicating code here is okay because old versions must be immutable - no maintenance nightmares. Obviously you'd want to move as much code outside the endpoint callback itself as you could to reduce the sheer amount of duplication.

...yes. You were saying that one request can have multiple queries and that multiple requests may want the same query, right? You're going to be executing queries and then passing the result to the request(s) that wanted it. Thus the uniqueness is on the query, not the request. Riddle me this: in what order do you want to execute these queries? I wouldn't say it's a bad practice, just that it's not the best/right way to do it. It's also kinda a different answer to a different question than the first solution. Why persist the query object? I would think that you should use the object as a vehicle for executing something and passing the results to whatever need them, so once that process is over you no longer need it. The data goes directly to the request. What?

Think about #1. You're using the requests as keys and the queries as values, right? Well, which of those two is going to be unique and which may be duplicated? You should have the query as the key and the set of requests as the value. But a generic SplObjectStorage isn't the best data structure. Please try to look at what else SPL offers. There is one particular design that will be more appropriate here. Consider the possibility that you don't actually need key/value pairs.

You're welcome. Let's see how this thread got here: Post #1: You ask if it's okay to use GET even though it's insecure. Post #2: Zane describes situations where it is not good to use. Post #3: You clarify that you are not dealing with one of those situations. Post #4: I ask about how you're using the URL. Post #5: You say you are using the URL in links for banners, and that you heard GET is insecure. Post #6: You give an example link with the HTML markup to generate it. Post #7: I say it's unsafe and you have to be careful. Included in there is the statement that "it certainly does not mean you shouldn't use" GET. Post #8: You are confused that I said it's unsafe, then post some PHP code that demonstrates htmlentities in a way that you are not going to use. Post #9: I explain what it means to be unsafe, and ask why you posted that code. Post #10: You believe I told you not to use GET. Then you ask if the code could display the banner without GET or POST. Post #11: I address the "not to use GET" by saying I told you already whether to use it - that would be post #7, and I thought I stated it quite explicitly. I address the "code could display the banner" by suggesting that asking about example code is pointless if it isn't the code you're actually going to use. Post #12: You say something sarcastic. Now, perhaps I got snarky because I was tired of having to repeat myself that using GET is fine to use if you're safe about it. Once again, you can use GET. Which is a variable, by the way, and not a function. (You can tell because of the leading dollar sign in "$_GET" and the distinct lack of parentheses when using it.) Nobody ever said you couldn't. As for the code, yes, that code is safe. But you aren't going to use that code because it's pointless to just output the two URLs and website name. You and I both know you are going to write some other code to do what you actually want done. So what I did, and will continue to do, is refuse to tell you whether that code is safe because I know for a fact that you would extrapolate what I said into some new direction and I don't know what that direction is. Maybe you'll be safe. Maybe you won't. I can't tell. So I'll reserve judgment regarding my answer until/unless you give the code you actually intend to use - or something clearly close to it.