requinix

Kinda hard to tell what code to add for the options or toppings or whatever if we can't see the code that adds the options or toppings or whatever.

Ah, okay, found the bug. Check your $params array more closely. What each item inside will be. Compare with the query that tries to use it.

Put your PDO into exception throwing mode and try again.

1. Look at PHP's filter functions. 2. No? The "link" is just text. Like any other text. 3. Now that you aren't encoding it, don't decode it. Yes, store it in your database (using proper procedures). Go ahead and implement it, then post what you did and we'll look over it.

Yeah, except while you added the player_id grouping you removed it from the columns to return. So there's no point. Take the query you just demonstrated and remove the GROUP BY on player_id.

https://www.lifewire.com/setfacl-linux-command-4093520 setfacl is your only option. If you cannot use it then you must give up on either the ownership or the permissions.

Well no, there's still more to this that should be addressed. SELECT players.player_id, players.deal_id, affiliate_deals.cpa, COUNT(players.deal_id) AS TotalPlayersByDeal, SUM(affiliate_deals.cpa) * COUNT(players.deal_id) AS affiliate_cpa_earnings FROM players INNER JOIN affiliate_deals ON affiliate_deals.affiliate_deal_id=players.deal_id WHERE players.affiliate_id=1 AND affiliate_deals.type = 'CPA' AND players.program_id=1 AND players.status=1 AND DATE(players.ftd_matched_Date) BETWEEN '2019-02-01' AND '2019-02-28' AND players.ftd_matched=1 OR players.affiliate_id=1 AND affiliate_deals.type = 'Hybrid' AND players.program_id=1 AND players.status=1 AND DATE(players.ftd_matched_Date) BETWEEN '2019-02-01' AND '2019-02-28' AND players.ftd_matched=1 GROUP BY players.deal_id When GROUPing BY something, you should only be SELECTing that particular something. Or if it's unique to a table, you could get it and other columns from that table. You are grouping on the players.deal_id, which is not a unique column in the players table. AFAIK. That means it only makes sense to SELECT players.deal_id. In MySQL, if you try other columns then you'll get some almost random value from one of the rows that got grouped together; some other databases like PostgreSQL are strict about not letting you do this. You want the player_id, deal_id, and cpa. The deal_id is unique to affiliate_deals, I think, so if you GROUP BY deal_id (either in the players or affiliate_deals table, it's the same value) then you can also get the cpa, but you can't safely get the player_id. You need to GROUP BY players.deal_id /* aka affiliate_deals.affiliate_deal_id */, players.player_id That will very likely change some of your numbers, but even if you don't recognize that now it is changing for the better. Or if it isn't then it's pointing out a problem with this query you didn't know you had.

Could you try a more specific question?

It would be equivalent to SUM(affiliate_deals.cpa) * COUNT(players.deal_id)

Where's your JOIN for the players table?

It's more obvious than you think: INNER JOIN affiliate_deals ON affiliate_deals.program_id=players.program_id AND affiliate_deals.affiliate_deal_id=players.deal_id (I know you wanted to fill in some details, and that's great, but this is literally just a matter of adding the "AND...")

It occurs to me that maybe you don't know you can combine multiple conditions into an ON clause. It's not just one single thing. It's a full expression. You can put whatever you want in there. I had capitalized that "AND" in my reply hoping maybe you would connect the dots...

So... problem solved?

So what you're saying is that rows in the players and affiliate_deals tables are related to each other if affiliate_deals.program_id = players.program_id AND affiliate_deals.affiliate_deal_id = players.deal_id?

Try picking up React(js). Installing it, its requirements, and the typical packages necessary to work with it, totals something like 16k files and a few hundred MBs.

I'm certainly not going to be the first person in line to say that Laravel is a good framework, I have to work with it every day and I hate it, but as far as MVC is concerned I think it does a fairly reasonable job of it. Sticking with the aircraft analogy, I see what I'm suggesting more like sitting in the copilot's seat: as long as one has the mentality of learning how stuff works rather than trying to shoe-horn their experience into it, seeing how a professional system does the job is a good thing. Yes, Laravel has a lot of crappy magic in it, debugging the internals is hell, and the few parts it does well are beyond the scope of learning MVC, but the point is not to copy and paste but to understand the principles. Like for MVC, routing goes through some configuration layer (routing), to a controller, to a view. If I had more experience with other larger frameworks then I'm sure I would rather recommend them. Have I mentioned I don't like Laravel? The real basics, like cutting down on procedural coding or improving code quality and reuse, can be learned anywhere, and I think doing that in a framework which already tries to urge you into it is as good a place as any. In fact using a framework is like the middle seat: you don't have the window to look out unless you're sly and you don't have the aisle to stretch out into, so you have to learn to stay within the boundaries established for you. Yes, that analogy was rather turbulent, but I've reached a cruising altitude with this aviation metaphor and I don't want to land while I still have fuel in the tank.

A JOIN will find all combinations of rows that match your conditions. If you look at the results, every row has slightly different data - the player_id, stats_date, or type. Each of those rows fits your criteria, so if you don't want some of them then you need to adjust the conditions accordingly.

I really don't know. phptherightway.com is the most reliable place for good PHP advice, but they don't have anything for MVC. Typically one discovers that after the fact... Perhaps the right thing to do would be to pick up a framework like Laravel. Or Symfony. They do all the heavy lifting. If you spend some time working with them, not only do you get to learn about them (a good idea) you'll understand more of how stuff like MVC and a variety of other things work.

That's stupid. Line limits are arbitrary. I mean, a basic PHP class without any code takes about 10 lines already. A good class takes as many lines of code as it needs and no more. There's MVC the principle and MVC the architecture. For the moment you want MVC the principle. It's about separating models (database and the code that handles data on its own right) from view (presentation and output) from controllers (logic primarily to connect models with views). It helps you keep code clean and prepares you for the next step. MVC the architecture is about how your application executes. When your first script runs for a request it will execute the controller, which may interact with models or do form processing logic or some other actions, and from there execute the view. The controller is typically a class because that's what it is in basically every other language and MVC implementation out there, but because PHP is not strictly OOP your "controller" could be code at the beginning of a file and the "view" the code that comes after. Professional means you get paid. It says nothing about your abilities or the quality of your code. There are far, far more bad PHP developers out there than good ones.

I don't see anything "first_child" on that doc page I linked, but that "How to traverse the DOM tree?" example looks highly relevant.

I saw. Just giving someone else a chance to say something. I'll stop by eventually.

Still no. I myself have tried the path you're looking at and believe me, it's not fun to work with. There are too many moving parts. Database queries suck. Adds joins to queries that didn't need them. It's just too complicated - and that's really something coming from me because I love over-engineering these things. Maybe don't think of it as changing the price but as taking one plan that was fairly successful and setting up another similar plan with a slightly different price.

Fragmentation? I don't see how. Yeah. So? What's wrong with having multiple plans? Your business needs change over time, it's okay. And you could, if you wanted. But isn't it starting to get rather complicated? You have to look up pricing at that time, features at that time... It sounds cooler and making it more complex might seem like it's better, but what are you really gaining from it? How much time is it going to take to make this work? What is the risk of something going wrong? Multiple plans fits better into your structures, covers all the requirements, and is easy to implement. I mean, surely you're not going to be changing plans every week, right? You design your plans now because you think they will last, and then you find out later that something needs to change or that you can get more conversions if you alter pricing or features, then you roll out a new plan for those people.

Precisely. It gets easier with practice. Don't be afraid to do something because you're not sure you're doing it perfectly. I don't mean stuff like security, you really should try to get that right the first time, but site architecture and layout and those things: it's okay if you aim for v1 now and consider redoing some things later. If you want to start a new thread, go right ahead. It is a weekend so it's a bit slow around here, but there are enough people around here with experience who could chime in.

Billions. It's cheap to do now, you might as well. IMO looks more professional too. You'd have to move everything into partitions. A wise observation.