requinix

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', 'noreply@example.com'); // or const USERNAME = 'noreply@example.com'; 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.

Great. ->setUsername(noreply@example.com) That email address in there is supposed to be a string. That means it needs quotes. See how '/vendor/autoload.php' and 'localhost' and 'Verify your email' are? Those are also strings. The password in ->setPassword(password) also needs to be a string, but it could be that you removed your password and replaced it with that just for the post, so for all I know the version you have in front of you is already a string.

Email addresses definitely have @s in them. Do you happen to be new to PHP?

A blank page means a fatal PHP error. What do your server error logs say?

Or you could install the most common Composer globally and "install" the other composer.phar inside the projects that need it. Or, if the project is for PHP >=7.3 then have both Composers use 7.4.

Yes, it can do that. Is that fact relevant here? Even if so, that still doesn't mean Composer 1/2 should be coupled to PHP 7.3/7.4. What it means is that you should be using the version of PHP necessary for the project. Just like how you would be using the version of Composer necessary for the project. But those are still two different things.

Unless you have some error messages that say otherwise, Composer doesn't care. You can run it with PHP 7.3 or PHP 7.4, it'll do the same thing. The only thing that matters is (apparently) Composer 1 vs. Composer 2. Saying that Composer 2 should be run by PHP 7.4 and Composer 1 should be run by PHP 7.3 is pointless. There's no difference.

/usr/local/bin/composer is going to be the same file regardless of whether `php` runs PHP 7.3 or 7.4. Install Composer 1 and 2 to different files, then ln "composer" to 2 since that works with most everything you have. For the other project that doesn't work with it, always run "composer1" commands. If you have errors with Composer then you'll need to post those.

You're getting a 403 with your own site? What do the server error logs say?