requinix

As long as you have a few specific questions that can't be easily answered through documentation or a search engine. The only thing it "means" is that the name inside the %{...} is a variable. What variables you have available are listed in the documentation. There's basically no reason to write 80 or 443. Those are port numbers. What you should be caring about is whether the request is HTTPS or not. Not necessarily. Some practices are outdated, some are harder to read and understand than others, some are dumb, and occasionally some are wrong. But the main criteria for deciding which to use is "does it do what you need it to do". Are you trying to tell me that if you put "htaccess regex tutorial" into Google you won't find anything relevant? Before you answer, consider that I am bothering to spend the time writing this sentence to refute your statement. If it takes you "a full 8 hour day" to learn what %{HTTP_HOST} means then I'm not sure anyone can help you. Maybe the problem is that you're not learning in an efficient way? Memorizing "percent sign then opening brace then HTTP_HOST then closing brace means it uses the HTTP_HOST variable" is going to waste a lot of brain cells if you have to repeat that for every single variable available. Yes, that's right. You know how in SQL there are database names and table names and column names and all that? You know how you can quote them, but don't actually need to unless the name is a special keyword or has some unexpected symbol in it? Same for Apache's configuration files. Quotes are mostly about when you need to write something that has a space. The quotes make sure the whole thing gets treated as a single value instead of multiple values. If you don't have spaces then you don't need quotes. I'm sorry you feel that way but 99% of the programming world does not work like that. And there should be a single year of school where teachers tell me everything I need to know about life. And there should be a single driver's ed. class that tells me everything I need to know about driving vehicles. And there should be a single politician who manages everything about a country. But there isn't. Because stuff is complicated and it can't all be covered in one place at one time. Typically people understand this concept early in life and then learn how to get information from multiple sources to ensure you're getting everything you need. (Unless you're American.) If you keep looking for a single resource that answers all your questions then you're not going to find one. Learn what you can from where you can then move on to the next one, and keep doing that until you don't have any more questions. That's true. Which is why you can't learn everything about mod_rewrite in one place. You need to learn regular expressions and understand a bit about Apache's configuration files and learn to a reasonable degree how mod_rewrite works and know how to test and troubleshoot what you've done if there's a mistake. The good news is that you're not expected to pick this all up immediately. Learning takes time. The bad news is that nobody can learn this stuff for you.

No, benanamen's code will not result in the same error. Try again.

...Yes. You know how you have your RewriteRule that sends a particular URL pattern to index.php? You do not have one for the new URL pattern. That means it won't go to index.php. And PHP cannot do anything if it doesn't get the request. You don't need any PHP for this. All you need is a new RewriteRule for the new URL, and it can still use your index.php with controller and action and id by simply specifying a default value for the one that's missing.

I've used barryvdh/laravel-dompdf before and I was pleased with it. But don't go into this thinking you can use the latest HTML and CSS standards. PDFs do not work like webpages. You may have to resort to using older styles of markup and formatting.

You cannot change the RewriteRule and also not change it 😉 If you want to support /shareboard/login -> controller=shareboard, action=users, id=login, then add a new RewriteRule to do that. That's all it takes. Because it's okay to have more than one of these as long as they match different URL patterns. When you do that, please clean them up so less stuff is optional. Because you have a problem with being too flexible on what you're matching. Try going to some invalid URLs and see what happens.

I feel like I should let you know: if I ever see you call me out in your threads, I do not reply to them.

Yes: the mod_rewrite documentation and any place that explains regular expressions. You're then expected to take all the knowledge you learn and apply it towards whatever ends. I can provide you with links to Google, if you'd like.

The documentation for mod_rewrite does explain what %{} means. ^ is not part of mod_rewrite per se but part of the syntax for regular expressions.

1. Read the documentation for whatever directives you want to use. 2. The term you are looking for is "regular expression". There are many places where you can learn about them.

In the $hue calculations? The first branch handles the $delta=0 case.

You mean when $delta === 0?

$lightness = (($cmax + $cmin) / 2) * 100; $saturation = $delta === 0 ? 0 : ($delta / (1 - abs(2 * $lightness - 1))) * 100; You're multiplying the lightness by 100 too early. This throws off the saturation calculation. Leave it as $cmax+$cmin/2 and multiply when you do the round() later.

So what's your question?

You know how if you put numbers in a query string, like ?value=123, and you try to get it in $_GET, the value is a string? Same thing. But what you're doing to total these numbers is... silly. Why are you putting these things into an array? Using Array.reduce? All you need is simple addition. You way overthought it.

First thing to do is read the documentation to understand what you will be working with: PDO's prepared statements If you're still not sure how to use them, there are plenty of resources on the internet about it.

You cannot take down the post, and even though I could it's already too late to stop people from seeing it. Whether you're vulnerable or not depends on how checkInput() works. But that aside, you should do what gw1500se suggested: change your code to use PDO or mysqli, which both support prepared statements that will get rid of the SQL injection problems.

I already did. I specifically said it shouldn't go there.

What you're describing makes me nervous, but yes: you probably should put that block (which doesn't need the Directory) inside your website configuration's VirtualHost.

That's why you would need that table subquery: to break your set of desired departments into single values. Then you can FIND_IN_SET each of those values inside the dept_code list.

SELECT... FROM... JOIN ( SELECT 1 UNION SELECT 2 UNION SELECT 3 ) AS not_an_actual_table There's a term for that subquery but I don't remember what it is.

And I agree that conf-available is not the right place for your RewriteRules. But you shouldn't be creating a new file in sites-available either and for basically the same reason: if you look through sites-available you'll find websites, and your RewriteRules are not websites. But they are used for a website, so put them in your site's configuration. As in inside the VirtualHost block. Alternatively, you could put the rules in a separate file somewhere (like within your application) and include it from inside the site configuration.

If you were using mysql_* functions before then you need to use mysqli_* functions now. They are very similar. Check the documentation because it is not just a matter of adding 'i's to the function names. Otherwise the easiest way to find out what you need to change is to test the site locally on PHP 7 and see what happens. PHP 5.6 to 7.4 isn't a huge set of changes, but there are a number of differences that aren't necessarily easy to spot. Also check the migration guides. Each guide between 5.6 and 7.4.

Take a look at the things in conf-available and see if your custom directives seem to fit in with what's there.

Honestly I don't quite follow exactly what's going on, but if all you need to do is cut off the hours at 20 then I'd think you should simply check the updated $sum and do a bit of math if it's above $horas.

I suspect there's a cleaner way, but the only thing I can think of now is to turn those department IDs into a fake JOINed table (using a SELECT 1 UNION SELECT 2 UNION... chain, or VALUES), then use FIND_IN_SET.