requinix

18 is not a question. It's simply a demonstration of how to use a table.

I'll repeat it: 1. Those two RewriteConds are only applying to the first RewriteRule. 2. Better than repeating those two RewriteConds six times, you should have all !-f !-d URLs go through function.php. Then it looks at the URL and determines which func/lang+func/lang+func+sub/whatever to use, like how the .htaccess is trying to do now. 3. You do not have any RewriteRules that will apply to /. That means Apache will use your index.html. AJAX is not authentication, you need all of this stuff for everything.

You still need to tell the AJAX what URL to send the data to. Don't do any redirects. Change the "url" to be whatever page it is you want to reuse.

Whatever code is in my_code.php has to be moved into the current file. Obviously. What happens after that depends on what the rest of the code looks like. If the file doesn't process POST data for anything else then you can use standard practices for handling form inputs (such as by checking if the REQUEST_METHOD is POST) and you don't have to change the AJAX any further.

Boosting is a bannable offense. https://support-leagueoflegends.riotgames.com/hc/en-us/articles/201751834-MMR-Elo-Boosting

If the two apps are different in the very nature of what they do then they should be separate. If the two apps are the same in nature but different in content then it will be better to use one database and have it distinguish between what content is available for what subdomain.

If you want to allow trailing slashes in your URLs then keep one and make the slash optional. But that still doesn't cover the root / URL. Also I missed that your first Rule only applies when the path does not exist as a file or directory. And index.html exists. Because: RewriteCond only applies to the single next RewriteRule. Rather than repeat those every single time, most applications do it a smarter way: route all requests through your PHP script and have it look at the URL and decide what to do.

Because none of your URL rewriting rules apply to / $_POST will work as long as you do not use the [R] flag or cause a redirect by some other means. $_GET will work as long as you do use the [QSA] flag.

Please don't hijack other people's threads for your own questions. How does it add the script to the head, and why does it need to know who inserted it?

Creating the regex is fairly straightforward: start with the literal string you want to find, escape any special characters that you don't want to be special (like the [ ]s), then substitute in stuff like (\d+) where you want to find numbers. The replacement string works much the same way, and you can reference the matched numbers from before using $1 or \1 (careful of the backslash). Honestly, you're probably overestimating how difficult this will be.

REST would suggest /documents/123/file(s).

Big disagree. Having to throw a cronjob to clean up temporary assets is a sign of problems. You're creating more moving parts this way, and yet you turned down multipart because it "adds complexities"? But the worst part is that you're creating two completely opposite flows for two similar situations. Whether an entity has one file or more than one file should not result in this much of a difference. Entity first, file(s) second. No temporary crap, no cronjobs, no inconsistencies.

1. $_POST data can't be trusted, not just inside of SQL queries but also inside of $_SESSION. 2. You are not using remotely acceptable password practices. Learn about password hashing using and password_hash() and password_verify().

Oh dear. Are you perhaps brand new to web development?

A valid approach. Base-64 increases the size of the request body but that doesn't make it bad. It is totally possible to do both. After all, haven't you ever used a web form that had you upload a file and submit other data at the same time?

What have you been able to come up with so far, and what happened/didn't happen when you tried it?

Read the documentation. The answer is there. If you looked once, look again. Also in the documentation. Find the section that talks about user-defined functions. This is the same question as 1 and 2. list() has documentation. And my code is doing the same thing. Read the documentation for list() to know what the first line does. Read the documentation for arrays to know what the second line does. Frankly, I find it hard to believe you have these kinds of questions after more than 600 posts on this forum. They are very basic features of PHP, and even if you don't recognize some of them, you should know how to find out what they are without having someone tell you to read the documentation 5 times. And I suspect that after you do learn about how my code works, you'll also have found your answers to how your code worked.

Do you really want an explanation? Or are you just trying to figure out why it's not working the way you want? Because if you just want to make this work, there is a much easier way of doing the whole thing: use preg_replace_callback() to run your own code every time it finds a match. Also means you don't need the replacement array since you're just replacing the word with a suitable number of asterisks, and str_repeat() can create them easily enough.

That {VRL_CALENDAR} thing looks like it's part of some templating language. You're either going to have to work with that, or find out what that thing does and make it happen yourself directly. For example, if that thing results in calling a function, you would just call that function yourself instead. Keep in mind that you're asking questions about something nobody here knows anything about. Don't know your website, don't know your application, don't know your framework, don't know the calendar... You are going to have to do research and work here.

Oh, yeah, you're right, I read it backwards. If you can make a PHP page that shows the calendar then you can put the URL to that page inside an iframe. Not really sure what the difficulty is here.

I don't know why you did that either. It doesn't accomplish anything. $tempArray and $matchesArray don't do anything, the code using them doesn't do anything, and all of that is pointless. Maybe it was leftover debugging code?

Is it just me or did you add more code and then try to understand what that code does? Your question seems to be about what's happening with the foreach loop, but that loop does absolutely nothing useful. It doesn't need to be there at all. The only parts that matter here are (1) the pattern and replacement arrays and (2) the preg_replace().

Could create a second BBCode tag that turns [attach] into [sharedmedia], so both tags would be supported. Actually I rather suggest that in case there's something still using or generating [sharedmedia]s - wouldn't want to break those. Would also mean not having to deal with the database. If you have a more specific question, like what code you have to write or regular expression to create, then you should probably ask that.

If it's made to show inside an iframe then that probably means it comes as a complete HTML webpage and not simply some embeddable markup. Maybe there's some sort of configuration somewhere to enable the behavior you want? Because if not then that would mean you'd have to start making changes to it yourself. Is there a problem with using iframes?

Really not sure what's going on. I'm inclined to think there's something going on with your browser, like it's remembering something inconsistently (I don't see any recent logins with your account so you've been logged in the whole time), but it could be possible there's some odd bug with IP.Board regarding... something.