requinix

Huh, it's actually doing the thing I thought it wasn't... Only thing left I can think of would be skipping E_DEPRECATED messages. set_error_handler("error_handler", E_ALL & ~E_DEPRECATED);

Given how dumb Smarty wants to be about this, suppressing the error looks like the only option. And since they're already doing that, I suspect you have a custom error handler? What's the code for that?

I'll give this one more try: 1. I've already mentioned that include() will return a boolean. Specifically, true if it was able to include the file and false if it was not. 2. You are using <?= tags instead of regular <?php. Remind yourself of what the special <?= form does. Do you know what happens when you combine those two together?

Post a sample of one of the times you did an include() that did not have this "1" problem.

Look closer at what you have here <?=include '../subscribe/sub_countdown.php'?> and compare it to the other times you've done something similar.

<?=include '../subscribe/sub_countdown.php'?> include() returns a boolean.

Do not translate things like keywords } Başka { // else fonksiyon aa(){ // function aa or CSS 60 piksel /* 60px */ görünürlük: gizli;görüntü: yok; /* visibility: hidden; image: none; */ or events dc.addEventListener("tıklayın", dd); // click You can write in Turkish names when you are the one creating them - names like for variables or functions.

If you need a single array then you'll have to do away with the prices objects and re-bundle their data into arrays. array( 0 => array( "prd" => 2380, "id" => "173489", "price" => "65.00", "stores" => array( "store 1", "store 2" ) ) ) Unless your spreadsheet builder thing is a pain, you could take that 0 => array and re-key it to the prd as 2380 => array. Similar to before, you can then use the prd every time to insert-or-update into this larger array: insert when there is no existing [2380] yet, update with array[2380]["stores"][] = "store 2" when it does exist.

Then that makes it a little easier. Figure out which of prid and id is the unique identifier - they probably aren't both equally unique because then why would there be two of them? - and use that for your array keys. You end up with arrays that look like $allPrices = [ // picking id, 173489 => prices { #2698 #container... } ]; $pricesToStores = [ 173489 => [ 'store 1', 'store 2' ] ]; That keeps the prices objects in one place, and using the prid/id as the keys in both places means you can easily look up which stores any one is associated with.

1. You need an array to put all the data you're receiving. $newArray isn't the greatest name but it'll work for the moment. 2. For each price item you receive from the API, check if you have it in that array already: if so then update its list of stores, otherwise add it. It looks like $Data is: an array of prices, where each price is a "prices" object, and that object has a private "container" array of the data. The problem here is that you can't (nor, in fact, should) add anything to that container array: it pollutes the concept of the "prices" object with data it doesn't know about. In your shoes, I think I would change the above approach to be: you have two arrays, one of all the prices with no store data, and another that tells you which prices are in which store. The new approach is: 1. You need the one array for all the data - let's say "$allPrices". You need a second array just to associate prices with stores - let's say "$pricesToStores". 2. For each price item you receive from the API, add it to $allPrices. Because there will be duplicates, don't add it blindly but instead index the array by the unique identifier; that'll be either the "prd" or the "id", I can't tell. 3. At the same time, add information to $pricesToStores for the price item and the store. They should be indexed by the prd/id as well, and the array values can be the set of stores it was found in. There's probably a small issue though: when two stores have the same item, is the data for those two items exactly the same? I think not. My guess is that the "prd" will be the same but the "id" will not (or vice versa). If you simply keep one of the prices in $allPrices then you lose what the other ones were, so perhaps you might need to retain all the prices together in a sub-array. But if you have to do that, does the price data mention which store it came from already? Because if it does then the $pricesToStores array is pointless. So after all that, a question: what does the price data look like for 2+ stores that have the "same" one?

My guess: because you're relying on elements IDs instead of classes. Can only use an ID once per page.

No. That's not possible. How much further down this rabbit hole are you going to go?

Don't. It won't accomplish anything.

In the modern world, we solve this problem with CSS media queries by hiding the elements of the page you don't want printed.

I'm not sure what you're saying either, but I'm pretty sure the response goes something like "yeah no, that's not how these sorts of things work" if not an outright "no, you can't force them into doing something like that".

Step 1: What actual data do you need to store, and what are the relationships between the different pieces?

It inserts what as what?

Are you exporting and importing from the same version of MySQL?

A snippet of the code you had posted is $sql_l = "SELECT * FROM users WHERE id = '$user_id'"; if ($conn_l->connect_error) { die("Connection failed: " . $conn_l->connect_error); } $sql_l = "SELECT id, movie FROM users"; $result = $conn_l->query($sql_l); Looking at that, it seems that the first $sql_l was what you intended to use and the second one overwriting it was accidental.

And what is the "issue" with indexing? Kinda missing the part where you mention what the problem is.

While it's good that you found the answer, one of the most beneficial parts of having a public forum like ours is that people having a similar problem can learn from your experience. So maybe next time, keep the post up and simply reply to yourself stating that you found the answer - and for bonus internet points, what that answer was too. I'm guessing your problem (which I can see as an admin) was that you were using the results from that second SELECT query which was fetching the first row from the table instead of the first query which was fetching the row specific to the user?

You don't need physics - just a simple if/else. Assuming you're talking about vertical and horizontal walls (like those of the containing box). Give it a thought yourself and you'll probably find it's easier than you expect. You're already calculating the ball's "angle" using X,Y components so consider what happens to them if you have, say, a velocity {x=1, y=2} at the time when the ball encounters a horizontal wall...

You probably ought to be using canvas for this instead of the DOM. You aren't "painting" anything here. All you need to do is use CSS's top and left to position the object where you want it to go.

There's a lot of files there so I can't personally spend the time to review the whole thing. Honestly, neither will a prospective employer. If you have specific questions or want opinions on specific files then that's something I could help with much more easily... A portfolio typically needs multiple smaller pieces of work that can be viewed, not single larger projects. Remember that what you're demonstrating is the sort of results you could provide to someone who will hire you - and most of them are not going to ask you to write a social network from scratch. They'll want a code sample to see that you know what you're doing with PHP, or that you can use a particular framework, or that you understand various algorithms or design patterns. I'm not saying that this Social-Network-MessBox thing is a waste of time. Every programmer should have a project or two they can work on during their spare time to keep improving as a developer, and this seems quite suitable to that end. But it's not going to be as useful in a portfolio.