requinix

... These pages, do they ever work? I asked because you have a session_start() immediately followed by an echo that doesn't include any HTML. That should mean there was some HTML being outputted before the code you posted, and if there weren't any warnings from PHP then you must be using some discouraged php.ini settings. What is the value of the output_buffering setting? Variety of possible causes. What sorts of URL paths do you have for the working and non-working pages. Do all pages under a certain "directory" work while pages under another one do not? What does your browser say about the session cookie settings? It should include a domain, expiration, and path. The cookie will only be sent for pages with that path prefix.

Also, is it always the same page(s)? And if you refresh (specifically refresh, not re-browse to) the broken page, does its behavior change? Does it show you as logged in? The code you posted, I don't imagine it's your real code. What is the real code? To find the session identifier, use your browser's developer tools to find the session cookie. It should be quite noticeable. Remember the random ID you see, then (with the tools still open) load pages until you end up getting logged out. The tool should also be able to show you the HTTP request sent to retrieve that page. In its request headers should be a Cookie header with the session ID. Check other pages that worked for an example. Is the Cookie header present and with the correct session ID? For your error log, are you sure it's logging everything? Do you have it set to log all messages from PHP - warnings and notices and all that, not just errors?

If you refresh working pages, do they eventually think you're logged out? Can you watch request headers in your browser to make sure the correct session identifier is being sent every time? Any errors or warnings in your PHP or server error log?

Do your URLs ever change domain name or HTTP/HTTPS?

Oh wait, is this one of those things where someone bookmarks Javascript code? Then it's sounding like you need throttling. Whatever is happening, don't allow it more than once every X seconds.

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.