requinix

Don't know either. I saw this a while back myself too and assumed that IPB would fix it themselves at some point, but obviously they have not. Looking at the template, it seems like the MFA screens were designed before a recent theme overhaul. Namely, they use a "ipsModal" CSS scheme when it seems they need to move to "ipsDialog". It's also missing out on color changes as the popup on dark theme isn't using the correct background colors (but it's still fine). I've made that change for the authentication popup: it's still rather wide but I think it's definitely better now.

You should avoid doing that, but as long as you don't have a whole lot of content then it probably won't cause any actual problems.

Your current HTML and CSS structures will not work for this. You have to come up with a version where the flex container's immediate children are two distinct elements containing the Left and Right boxes. In the most minimal form, <div class="this-is-the-flex-container"> <div>Left</div> <div>Right</div> </div> Showing and hiding things for desktop vs. mobile views is extremely common. Just make sure you do it in a way that is good for the user.

Clearly they were wrong because you did what they said and it didn't work. flex and flex-direction only affect the element's children, not all its descendants too.

The HTML is structured as div.home-promo-client-left > div.grve-container > div.grve-row > div.grve-column > h3 > span. The flex and flex-direction is on the home-promo-client-left, but the Left and Right elements are way down in the grve-columns.

How about a screenshot of what part of the page is wrong? And a description of what you want it to look like?

If it works for him then that's because he's using a non-standard PHP configuration which allows him to get away with bad practices such as processing form data and sending redirects in the middle of output. Again: what he is doing is wrong. You should stop following that tutorial and instructor and find someone else to learn from. Like Barand said, this type of code should happen at the start of your script and the output should happen at the end of your script. Mixing them together causes problems.

Forget "better". Look at what the two options mean and decide which is more appropriate for you. The first option prevents the autoindex ability from even existing in the first place. Use it if you don't want to allow anything to do indexes at all, ever. The second option disables the index ability for every directory under /var/www. Use it if you don't want to enable indexes by default but might possibly want it on a case-by-case basis, eg. with a .htaccess and/or a more specific <Directory> directive somewhere.

So the client doesn't pick which ones they want shown, they only pick how many ranked ones and/or how highly ranked something is to be shown in the list? In other words it's just a UI customization feature that I'd argue isn't even a thing that clients should have to/be able to bother with? But to the question. Sounds like you've decided that the "ranking" is essentially just a usage counter? +1 every time someone uses it?

Doesn't the ranking thing conflict with the which-ones-to-display thing?

Just realized that my explanation needed a bit more: simply splitting on tags gets you text vs. markup, so the step after that would be scanning the array of alternating text/markup and skipping past the text sections that are between "<a" and "</a>" elements. A little more work. The obvious alteration to that strategy, and I expect this is what you did, is split not on any tag but on a "<a...</a>" string, then deal with an array of alternating non-links/links. Still leaves you with the problem of accidentally replacing tags within markup, such as the "src" of an image. An alternative to preg_split is preg_replace_callback, where you trade operating on an array or three with performing your tag replacements immediately. Still has the same text vs. markup/non-link vs. link problem. There will be a performance difference, not sure how large or in what direction, but that's not the first thing to worry about. The main problem is the accuracy of what you need to do. Consider a tag like "href". If you use a lookahead* then that won't stop you from replacing it within an <a> tag. You end up having to create something more and more complex to eliminate edge cases until you end up with something incomprehensible. Once you've done that, performance does become a secondary concern if simply because of the sheer complexity of the regex. How many <a>s are distributed within the text? Note that every single time the engine tries to replace a tag it has to look forward until it finds an <a> or </a>, and that work will cost time. If you go with the split approach then you can eliminate the lookaheads entirely and allow the engine to optimize around a simple \b$tag\b or \b(tag1|tag2|...)\b expression. The downside is a bit more work ahead of time, plus the additional memory around duplicating the document into string pieces inside arrays (or with preg_replace_callback, dealing with tons of function calls). Honestly, though, PHP is not the sort of language where you should be worrying about the minutiae of optimizations and instead focusing on the larger wins: readability, maintainability, and general algorithmic complexity. * You start by looking for a </a> as an indication of failure, but that will always match if there's any link at all later in the document, so the lookahead has to ensure that if there is another "a" tag that it is an opening tag - or in more precise words, it is not true that he next opening or closing "a" tag is a closing tag.

PM me some details and I'll look into it.

You're also going to have a problem any time you try to replace words like "href". Use preg_split() to split the text into an array of alternating text and markup by looking for opening and closing HTML tags. preg_split('#<\w+[^>]*>|</\w+>#' Perform your replacements on the text-only items of that resulting array; for efficiency's sake, rather than loop through the array yourself, it would be better to split the array into two and give the text one's whole array to preg_replace.

There are multiple places where character encoding matters. Make sure you have UTF-8 set: - For the database's default charset (use SHOW CREATE DATABASE) - For every table's default charset, which is inherited from the database at the time it was created (use SHOW CREATE TABLE) - For every column's charset, which is inherited from the table at the time it was created - For all connection related settings (use SHOW VARIABLES LIKE '%char%') - if you can configure everything at the server level that's best, otherwise you'll have to configure some of them in your code - For your PHP files as your editor/IDE creates them, and make sure it does not include a BOM which most don't - For your HTML pages, using a Content-Type header or better a <meta charset> directive in the markup If any of those does not match the others then you'll have problems.

What "command" to do what?

You might be able to search for a div with a class that starts "css-" and ends "-metrics" (check that). I think I would then "render" the whole thing to text and run a regular expression to parse it.

It's been a few years but IIRC (not that I have any reason to doubt it) what gizmola said is what happened: someone used an exploit in IPB to upload a PHP file they could then browse to. Besides updating IPB, we also took measures to prevent PHP from running files in the uploads directory, so anyone browsing to one will only get a dump of the source code.

Take it one step at a time. All you need to store in the database is a partial file path. If you know that the file is going to be in the img/ directory then you don't need to store "img/" in it - let alone "/opt/lampp" and everything else. Once you have that file path, the "src" you give to the <img> has to be the right relative URL to access the image. If your files are stored in /opt/lampp/htdocs/<site>/img/<name> and your website root is /opt/lampp/htdocs/<site> then your image would be <img src="/img/<?= $the_partial_image_path_which_weve_decided_is_just_the_name_part ?>">

So once again, what are you trying to protect yourself against? People getting root access on your server is extremely rare and not something regular people need to worry over, but SQL injection allowing someone to scrape your database is something to be concerned about, and it's not unreasonable to take measures to protect specifically what's in your database...

Not getting the impression that you read my reply. Are the files still there after the first submit? They only disappear after the update? Did you try to upload new files in your update? And once again: given that this update code can overwrite old files with new files, what are you doing with the old files? Do they need to be deleted?

If they have root access then there is nothing you can do. No amount of encryption can save you from that.

You're overwriting the filename columns in your query. Make your code not overwrite those columns unless it has a new value. By the way, if there's a new file, what do you do with the old one?

Looks to me like Apache is doing exactly what it's supposed to be doing and that okhttp is the one at fault. TE specifies support for transfer encodings in the response. TE must never include "chunked", but okhttp is doing that. TE is also optional in that a response may not use any transfer encoding at all, as Apache is doing there, but okhttp isn't respecting that and/or your problem is due to something else.

I expect there's some degree of caching involved, but it could be something as sophisticated as not tracking you as doing something unless you've spent a few seconds on it.

What I would recommend is not abandoning this because you're having a small problem. Did you confirm that fetch-tours.php is executing and returning the correct data?