requinix

The non-www one does an infinite redirect. Except it works, yes. Like I said, there is no way for mod_rewrite to do (cond AND cond) OR cond. There is a way to do it all in one single RewriteRule, but it means more processing overhead. Besides, having two RedirectRules for two different reasons makes sense: one of them handles non-www domains, one of them handles https. Yeah, it would be nice to combine both, but it doesn't actually matter.

I don't know where you're getting that button stuff from. Refreshing a page starts everything over from the beginning. A page won't interfere with a future version of itself unless someone writes code specifically designed to do that. You say it appears after a refresh. That sounds like you're saying that it is now appearing every time. What precisely is it that you do and don't do when the page works and does not work?

Did you check if Apache is running? And keep in mind that every device directly connected to the internet is going to be probed by various entities across the internet. Make sure you keep all your software up to date with the latest patches.

A white screen means your PHP code broke. Look in your server error logs to find a reason why. Also, when you tried going to /home, did you watch what happened in the address bar? You saw it change, right? Did you pay close attention to what the new URL was? As for those links, the solution is to fix them. Don't write index_pl.php?src=home. Do write /home.

I may be old, but last I knew phpBB and vBulletin were still the two reigning kings of free, traditional-style PHP forum platforms. But are you sure you want a forum? For an ecommerce site? Maybe what you need instead is some form of product discussion capability? Disqus is something I see in a variety of places. Not free, but cheap, and if the shop can't afford $9 a month then it's not profitable enough to survive in the first place.

Arbitrarily capping the number of links is not going to solve whatever problem is causing the code to run when it should have stopped. You need to find out exactly what the problem is so you can fix that.

If that's exactly what your host suggested then it's wrong. If the problem is the unnecessary redirect, what if I told you there is only one redirect (if done correctly)? RewriteCond %{HTTP_HOST} !=www.domain.com RewriteRule (.*) https://www.domain.com%{REQUEST_URI} [R=301,L] RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] That's slightly modified from other versions because today is an odd-numbered weekday.

Moved. This sounds rather unusual. Are you sure that's how it goes? You are definitely logged out because if you refresh the page you are indeed logged out, you click the Sign In at the top right and get the popup, you enter your information, it says the username/password is wrong, you refresh the page, and you're logged in? You followed those exact steps?

It's not possible to do that. What are the conditions? There might be a way to alter them to work without "parentheses".

Apache does not fix your long URLs to be short. What it does is allow you to use short ones. In other words, you're thinking about URL rewriting backwards: short URL goes into the browser, long URL is what runs on the server. So go to /home and see what happens. Spoiler: it won't work. 1. Try adding an [R] flag to both of those RewriteRules so you can see what is happening. 2. RewriteConds only affect the single next RewriteRule. If you want them to apply to two RewriteRules then you need to use two copies of them.

Fix the RewriteConds so they're on separate lines and fix the RewriteRules to use the correct rewrite destinations according to the "long" URLs you want.

Fixed: it was set up for the Dark theme but not the Light theme. Also checked the other custom CSS rules, but besides a small underline thing, there weren't any other rules (not related to coloring) that Dark had but Light was missing. However, it's possible/probable there are some HTML template differences.

What's your question? If there's a way to not have to copy and paste so much code?

I really don't get the impression that you're reading my replies. They both told you that GROUP BY wasn't the answer, and the second one told you not one but actually two different methods to get the information you need (one probably more useful than the other).

I'll rephrase what I said: GROUP BY is for grouping multiple rows together into one row. Like, say, "group all of the records together and give me one row that counts how many there were". So let's say you fix the query so that it returns the ID and which column it was that didn't have the value. And say you get both sets of results combined into one query. Duplicate IDs are going to show up twice. How would you end up processing those records? You'll show the user once as not having a firstname, then somewhere else later you'll show the same user again as not having a lastname. Wouldn't it be better for the person looking at this page to see the ID and that both fields were empty? Which means now you should come up with a query that shows the ID and indicates the firstname if it's empty as well as the lastname if it's empty. And the condition for a user to show up in this new list is the same as before but slightly different: the firstname is empty or the lastname is empty. And you know an easy way to indicate whether the firstname or lastname is empty? By returning the value of the field and literally checking if it's empty. All that leaves you with SELECT id, firstname, lastname FROM table WHERE firstname = '' OR lastname = ''

GROUP BY is for grouping multiple rows together. That's not quite what you want to do here, is it? What you want is possible, and rather easily, but first a question: when you read back the rows from this single query, how are you going to know whether each one is showing you an empty firstname or an empty lastname? (Does the distinction matter?) And note that there's no point returning the firstname or lastname because you already know what they're all going to say: they'll be empty strings.

It can be whatever, as long as stuff exists in the way it needs to exist at the moment it needs to exist. So you can getElementById a variable, sure, but the thing you're trying to find has to be on the page - not just sitting in a variable you got from AJAX.

It wouldn't redirect the user. Normal RewriteRules make their changes internally - the user wouldn't know it happened. Only when you try to redirect someone to a complete URL somewhere else on the internet (ie, "https://whatever/path") or you use the [R] flag will the user('s browser) be told to do something else.

I think you've got your order of operations mixed up. The pear DIV is inside the AJAX's HTML, so right now you're trying to insert that HTML into itself. There's also nothing in there targeting the "apple" element. The pear DIV has to exist on the page for you to insert something into it. It should not be in the response itself but rather already on the page, and the response would be just the apple part.

Are you talking about this forum or your own website?

1. If you want to submit other pieces of information at the same time you upload a file (or other blob) then yeah, multipart is the way to go. 2. I think what they're saying is they support multipart for specifying multiple values but not JSON for specifying multiple values. Any of those values themselves can be (strings that look like) JSON.

That's exactly what would happen if the code I pointed out about returning an error was happening. There's an easy solution to this: when you error, (1) use http_response_code to change the response status to 500, and (2) use an error callback for the AJAX that alert()s the responseText. Honestly, you should be using http_response_code() for the 200/201 thing as well. Pretty sure that was the original intention too.

Well your code, bro, very clearly includes the id in the WHERE, so... My point was that if there was an error then you would not get an alert() about it. The code would die with an error in your browser's developer console, which you may or may not be checking.

echo "Error: " . $query . "<br>" . mysqli_error($con); That is not valid JSON. If this gets outputted then the AJAX code will break because JSON.parse() will fail.

The example might have been using a constant. Those are pre-defined values like define('USERNAME', '[email protected]'); // or const USERNAME = '[email protected]'; In the first one, the constant is created with a function, and the name of the constant needs to be a string because it's passed as a value to the define() function. The second one shows a special syntax for creating constants, where the name of the constant doesn't have to be a string because that's how the syntax works: name of constant = value of constant. Note that for both of those syntaxes, the email value is still a string.