requinix

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?

Seems alright, but there are 5 versions of FullCalendar and I don't know which one you're using. Check the browser's error console for any messages, and use its request monitoring tools to make sure that your fetch-tours.php really is being called and returning the data you think it is.

$title = isset($row['name']); $start = isset($row['dep_date']); $end = isset($row['ret_date']); Are you sure that's what you want to do with those variables?

Data does not simply disappear. If you name those columns in the UPDATE then only those columns will be updated - unless you have some sort of other magic happening in the table, like triggers. And what's the deal with student_id? Why is it in the UPDATE but not the INSERT? Unrelated, hopefully: did you know that MySQL has a INSERT... SET syntax? INSERT INTO semakan_dokumen SET email = '$stdEmail', surat_tawarn = '$fileName', ic = '$fileName1', That looks a lot like the UPDATE syntax, doesn't it? If you build one string in PHP with all the column=value assignments then you could use it in both queries. (Don't forget that the UPDATE query cares about student_id in addition to the other columns.)

The server must be capable of decrypting the data on its own. Can't get around that. But you're going about this the wrong way. First, ask yourself what are you trying to protect against?

Here are some relevant facts: 1. max_execution_time has some nuances in exactly what counts towards the limit. For instance, on Linux systems it counts only the time PHP itself is working, and therefore will not count time for disk reads which are performed by the system. 2. The average hard drive can stream data at about 125 MB/s. An 8 GiB file would take about 8000/125 = 64 seconds to read in full. 3. PHP's memory usage is not a perfect correlation to the underlying source - especially given that md5_file() will be performing some amount of hashing work in addition to the literal file reads. 4. PHP claims memory in blocks. 8MB = some number of blocks taken * the memory used per block. Do you want to know the exact truth of what PHP is doing, or would you like to continue investigating to see if you can discover it for yourself?

Sounds like you've already given it a situation where it would have run out of memory and it did not...

Your code will disable the button that was clicked. Are there other buttons that also need to be disabled? All your screenshot shows is the Submit and Update buttons.

So for each of those columns, you want it to be that the column IS NULL OR the column = some value?

What is an sample of the HTML you're trying to locate? Some actual HTML. Make sure you're doing a View Source of the page and not looking at the rendered version through the browser's developer tools.

Looks like that part is dynamically generated. Going to be a real pain to use DOM to find it. But why bother? The only thing there is some static text and a link with a static URL.

Question: are there going to be people who are "members" of multiple towns? Not the sort of thing I would expect, but then again I can't tell what it means to be a "member" of a town.

Have you considered looking for an error message that might explain why you're getting a 500?