requinix

Yes, it's true that we do like quick answers, but only to quick questions: very often the background information is not just useful but even significant and can affect what advice should be given. Your criteria are that you have an authentication system that is applied for individual directories where one username and password (each) is sufficient, and that you are using Apache. Right? https://cwiki.apache.org/confluence/display/HTTPD/PasswordBasicAuth You can set up a single file containing all the information for all the directories, each one with a different "username", then instead of Require-ing any valid user, you require the specific "username" for that directory.

So the answer to the question I asked is "no, I do not want a different username/password for each person". Let's try another one and see if we can reach the answer with fewer posts this time: Are you using Apache?

It will be either a string or an array. If you want to protect against that, a simple is_string() will suffice.

Thanks for making an account here and notifying us that you had a question and asked it somewhere else. We'll be watching that carefully.

If it's a string then it won't be ===false. Because it's a string. Same for ===null. Maybe what you're looking for is isset($_POST["whatever"]) && trim($_POST["whatever"]) != ""

You have two forms, one to let you open the file and another to let you save contents to the file. The first form has the filename, the second form has the file contents. The question for you is: why would the second form also have the filename? You didn't put a filename in there. It's just the textarea. Your browser isn't going to take the filename from the first form and include it in the second form's data. So put both into one form. Filename and file contents. Put the two buttons into the form too. Since it's just the one form now, you'll need a different method to determine what your code should do. Solve that by giving a name to your button, and you might as well use the same name for both since the user can only click one of them, then checking (a) if $_POST has that button and (b) what value it has. Side note: <button> buttons are better than <input> buttons. <button type="submit" name="action" value="open">Open</button> But before you do any of this, open up your php.ini (should be where you installed PHP), find the error_reporting and display_errors settings (the real settings, not the ones that are part of the documentation inside the file), and set them to error_reporting = -1 display_errors = on Then restart your web server and try running your code as it is right now. You should see a number of error messages. Do the changes I said above and run it all, then if you still see errors you need to go in and start fixing them.

Yes, a different username and password for the different directories, but do you also need a different username and password for each person? If so, how many people and do you need a full user system where they can log in and change passwords and whatever, or can you simply assign them passwords and that's the end of it?

What do you mean by "save the changes"? What is supposed to be saved? Where?

I don't. You have no business trying something like installing software on a server. But I can't stop you. So if you're going to anyway, don't do anything except what the installation guides tell you to do. Don't touch files, don't go snooping around for stuff you won't understand, just forget it all exists and follow the steps to install. You probably messed something up. Delete all the files and start over again.

Moved to MySQL. You address this problem by refactoring your application so that the problem doesn't exist in the first place. Storing the platforms as individual columns is not a good idea. For one, it puts you in the situation you're in now. For two, it makes it harder to support whatever platform will be popular next year. You can generalize each platform as having a URL to the user's page. Probably don't need much more than that. Create a table that lists all the platforms you support, with an ID (like every table should have) and a nice name. Want to support a new platform? Add a row. Then create a new table that contains a row for each combination of user and platform URL; if the user has a Facebook and a YouTube page then there will be two rows in this table. Add to that this concept of a number of followers. That's two new columns in the second table: one for the minimum and one for the maximum numbers. Or whatever. Then querying is easy.

Did you install the PHP sources too?

Fortunately PHP 7.4 won't let it happen.

If you process credit cards then you can find out whether the charge was successful immediately. No problem. Some other payment methods are instant like that. For payment methods that are not instant then you need to tap into some mechanism where they notify your site of a change. For example, PayPal has IPN which pings your site when activity happens with a transaction. You thank the user for the payment and then wait for the IPN message that confirms the payment happened - it typically happens within seconds - before you give the user access.

But here's the question: what is that expression going to evaluate to? 2 or 4? The problem is the last line. It uses $i++ and $i in one statement, and that's a no-no. Did you see when I mentioned sequence points earlier? Look into it.

Obviously it isn't real code someone would write. Not all of it. But that last line, that's something one could reasonably write in some circumstance.

Yes, that describes how one pre-increment operation works on a variable. That page does not explain how one or more pre- or post-increment operators on the same variable work when in the same expression. The concept is called a sequence point. Look into it: most everything you'll find will talk about C/C++, but it applies to PHP as well.

Not necessarily. PHP makes no promise that the $i on the right happens before or after the ++$i on the left.

That's right: .htaccess URL rewriting only tells Apache how to understand the new friendly URL structures. It doesn't also update the links on your pages for you.

I suggest that you try to describe your situation and your problem to us so we don't have to try to jump into the middle of it...

Check your error logs in case something happened. Also try setting up and submitting an HTML form to see how the script reacts.

500 error? Go to the error log. 500 error? Go to the error log. 500 error? Go to the error log.

Do you need a full user authentication system with registration and login and all that? Or will you be granting access to a fairly small number of people that is unlikely to change? Because if you're using Apache (you probably are) then there's a stupid easy way to do this using its built-in HTTP Basic authentication.

It's generally not good design if you have to pull a path like that dynamically. A script sending the email should simply write the required /LifeSaverHTML/Details/20 or whatever directly. By the way, dirname on the REQUEST_URI can be very easily fooled. Definitely don't do that.

I'll do it in a few minutes.

If you've already added some custom CSS for stuff then you might as well add some more custom CSS to deal with this...