requinix

https://www.php.net/manual/en/migration70.php https://www.php.net/manual/en/migration71.php https://www.php.net/manual/en/migration72.php https://www.php.net/manual/en/migration73.php https://www.php.net/manual/en/migration74.php

Yeah. I got that.

This is something that should be solved on the webpage itself, not from within PHP. Specifically, solved with CSS. Which is why I've moved this thread into the CSS forum. I don't suppose this website is publicly viewable, is it? That would make it much easier to give suggestions on what to do... Screenshot of what it looks like? Do you have any custom CSS already applied to the site?

It's not about the checkbox being checked. The problem is that the $stmt3 query returned a row, you read it, and that you didn't finish reading until it was done. Unbuffered statements (which you are apparently using) must be fully read from before you can start another query, and "fully read from" means you don't just read the one row you were expecting but you keep going until you don't get any more rows. But the solution here isn't to do that. The whole point of prepared statements is that you only need to do one of them. Preparing the same statement over and over again inside a loop is the exact opposite of how it should be used. Prepared statements should be prepared once, have their input variables set up once, and then what you repeat in a loop is setting the variables to some new values and executing the statement. But the solution here isn't to do that either. You're potentially running a bunch of queries here, right? One to get the list of categories, then one for each of those categories to see if the post uses it. Wouldn't it be better if you just ran one query for all the categories and it told you whether the post used each one? SELECT bc.catID, bc.catTitle, NOT ISNULL(bpc.postID) AS inuse FROM blog_cats bc LEFT JOIN blog_post_cats bpc ON bc.catID = bpc.catID WHERE bpc.postID = ? ORDER BY bc.catTitle Prepare that query, bind in your $postID, execute it, then fetch all the results from it. Each row will tell you the category ID and name, as well as whether it is in use for the post.

Current standards are to create responsive websites using CSS media queries. Don't detect the user agent, don't detect mobile or desktop. No Javascript. You should be able to open the site on your desktop browser, shrink the window, and see the mobile experience.

Look in your error logs.

No, for assorted reasons including "I don't know what $item is so I don't know how to check what category it is in". If you can at least figure out that part, if ($item->???() != "courses") {

If you need to post more code, please use the Code <> dialog to do it. Much easier to read that way. Seems you would handle the product category in foreach ( $items as $item ) { $product_id = $item->get_product_id(); $product_ids[] = $product_id; } there. Like foreach ( $items as $item ) { if (/* the product category is good to show */) { $product_id = $item->get_product_id(); $product_ids[] = $product_id; } } How you go about deciding whether to show, I can't tell. Do you know what method(s) you need to call on $item?

The change you need to make isn't in there. Where is my_purchased_products handled?

Sounds kinda complicated, doesn't it? Having to store the current balance for each row. And it's only correct at the moment in time when the row was entered. So if you want to make a change you have to go find the most recent transaction to see what the balance was after it finished. Don't do it. For the moment, the balance is the sum of all transactions. As in do a query that gets a SUM(add) of all the transaction. That's your balance.

Too bad there aren't any places on the internet where you can upload files, huh?

According to the README, the constants are called "MARGIN_LEFT" and "MARGIN_RIGHT".

Use your operating system's package manager. If their repositories are not up to date, find a third-party repo that is.

Well for one, var json = JSON.parse(JSON.stringify(data)); don't do that. You're starting with an object, turning it into a JSON string, and then turning it right back into an object. There's no point. That aside, one improvement would be to use object syntax instead of array syntax for accessing members. Array syntax with [ ]s is fine when the name is in a variable, or it has some weird name you know but can't write out (like it has hyphens or symbols), but for names like "students" there's no need. Example: for (var key in data.students) { (note that this is using the original data variable you started with) An easy second thing is semicolons. Control structures, like for loops, don't need semicolons after the body.

I'd be nice if there was a permission option specific to the thread creator. Replies from other people could be disabled but replies from the author could be allowed.

My intention is to find a way to put a warning on the reply page itself, but I'm not sure there's a solution for IPB that (1) doesn't require buying a damn addon and (2) doesn't require hacking the page template (too much).

Due to the number of people attempting to reply to threads, despite the instructions at the top of the forum page that says not to, replies have been disabled. This may be revisited in the future.

What is the URL in your address bar when you browse to index.php directly? What is the URL in your address bar when you go to the page containing that form? Do you see any differences between the two other than the name of the file at the very end - and I do mean literally anything different other than that?

Get from cookie, if not set then start at 0. If value is >=2 then don't show popup. If value is <2 then increment, save to cookie, and show popup.

If you aren't already involving PHP in this process then there's no need to bring it in now just for cookies. maxxd linked js-cookie. You can install and use it that way - look at the CDN section of the readme, it's just a matter of adding a <script>. Otherwise the page I linked has, somewhere on it, a couple functions to read and write cookies. You would copy and paste that into your code somewhere so that you can use it.

Unfortunately, cookies in Javascript are difficult to deal with. Still. After all these years... Check this.

The "check" is actually the result of the animation. Look at the animation itself for where you can change the color.

If you have problem getting your code to work then a good first step would be to post said code.

Sounds like what you really need is to use the cookie when deciding what list of deals to show...

It's a little more than just changing the code. Right now your site is basically the same for all countries. That's fine, but it doesn't really lend itself to there being multiple URLs for the variations. If you were to significantly change parts of the page, then new URLs would make sense. Honestly, I think what you have now is fine: use a cookie to track the localization being applied to the page. Why do you want to have different URLs?