requinix

Then either (a) what I said about cookies/sessions, or (b) the whole thing doesn't make sense. How could having a bookmark possibly give someone an unfair advantage? It's ridiculous. If you don't want direct access to the page then what you want is to require indirect access through some particular flow. So what you do is enforce the flow.

No. No no no. Do not do that. It is pretty much always a bad idea to make it harder for people to browse your website. I don't know what this "advantage" is, but someone typing something into an address bar should not be sufficient to give it to them. If there are other pages that must be visited then you should enforce that with cookies or session data. ...which may be what you're thinking about. If you want people to hit page A before page B then you make sure that (1) page A sets some data, like a cookie or session variable, to indicate the page was visited, and (2) page B reacts in some appropriate way if that data is missing or invalid or expired or whatever.

Caching isn't bad, you know. As long as you're not using Expires, it's totally okay to tell clients that they can cache stuff. Mostly assets like CSS and Javascript and images - things that don't change often. In fact you should do that to help reduce stress on your server and your wallet.

You cannot really control how people arrive at your page, no. A bookmark or clicking a link or typing it in the address bar are all essentially the same thing. If you have a problem when a script runs that much then have you tried addressing that?

I doubt it's broken. More like Edge updated something between versions 38 and 44 to work better.

Unless someone at Doctrine did something wrong, a patch version update like 8.5.2 -> 8.5.4 or 2.7.2 -> 2.7.3 should not break anything. I would first look at the two minor version upgrades: doctrine/inflector (1.3 -> 1.4) and doctrine/common (2.12 -> 2.13). But is that really the problem that needs to be solved? Did you look into the foreign key constraint error first?

That data shows an array containing an object. Decide whether it should be returning an array at all (tip: only do it if you need to support returning multiple objects) and adjust either the PHP or the Javascript accordingly.

Use the correct domain name for the URL. I don't know what it is. You might not even know what it is. But one of those two should be the "proper" domain. If your tool thing complains about preloading then add preloading. Which you do by preloading the actual URL that your page wants to load. Not that it makes sense to preload something that's being embedded right into the page...

Spaces are common and a + is a lot easier to skim over than %20.

1. Because + is also allowed for a space. 2. An actual plus will be encoded as %2B.

1. You cannot output JSON and then go on to output a bunch of HTML. 2. What happens if the productid doesn't match anything?

You could help yourself by sorting the array (or sorting a copy of the array) according to subarray size, then only searching arrays that are at least as large as the one you're processing. Improving efficiency much beyond that will probably result in some non-trivial code that's not really worth it for just 12 subarrays.

More efficient way, sure. But it might not be worth the effort. How many arrays do you expect to deal with and how large will they be?

I'm not prepared to go through 20 minutes of video to find what you're talking about. RewriteCond %{REQUEST_FILENAME} !-d That makes sure the next RewriteRule only affects URLs that weren't for a directory. RewriteCond %{REQUEST_FILENAME}\.php -f That makes sure that the next RewriteRule only affects URLs that exist if you were to take the path and add a .php extension. /view/inbox is not a directory (good) but /view/inbox.php does not exist. So there will be no rewriting. That second RewriteCond is the problem. Check the docs to see what it needs to look like so that it instead makes sure to only affect URLs that aren't for a file. Hint: it almost identical to the one about directories. When that's fixed, spend a moment to learn about regular expressions in Apache's URL rewriting, then take a closer look at what your RewriteRule is doing.

It seems like you're mixing two different URL rewriting schemes together: the normal version where you look for files that don't exist, and an alternative version where you automatically add a .php extension. Use one or the another. Not both. In your case you are not adding the extension automatically because the URL is like /view/inbox and you don't have a /view/inbox.php script. So replace that second RewriteCond with one that ensures the REQUEST_FILENAME is not an existing file. Then you'll have another problem. Make your script print out $page and you should be able to see what's wrong fairly quickly.

Have you considered that maybe the problem that should be solved is the one where it wasn't displaying the excerpt? What code did you have for that, and given that it was not displaying then what was it doing?

I know.

Actually I was hoping for the HTML markup. Not how your browser is displaying it to you. Do a View Source.

You're parsing HTML as text. Don't do that. What's the actual HTML markup for the stuff you're reading?

Too magical. For each page where you care about this, call a function with an identifier for the page. I don't mean "home.php" or "admins.php". I mean like "home" or "admin" or whatever label you want. The function grabs the rank from the session and looks it up in the database. With a query. And reacts accordingly.

Make the redirect happen in your PHP.

I don't see where MySlider is defined. What's your complete code now?

If you don't care about other records once there's a status_id of 3 then why does the department matter?

So I guess what you're saying is that the dept_code is irrelevant?

No. Only the pd+chk pair check for the dept_code. But you are not looking at the pd+chk data. You are looking at the pd+ps data. Put the WHERE back in and make the chk join a LEFT JOIN.