requinix

That's called "security through obscurity" and it is not security. A local installation + SSH is much more secure and it's very easy to do.

What kind of proxy? Because a regular HTTP proxy isn't going to have this MIME type detection problem.

Was it a post here that told you to use execCommand, I ask even though I already know the answer?

Let's forget unpack() for a minute. Is the variable a number or a string? Because what you have in this code $binary3 = 01111111; is not a binary number.

Please find another source of information besides w3schools, which is known by the programming community to often be misleading and wrong.

Maybe not. Running /usr/bin/file from PHP is another option. Deciding based on file extension is another. All depends what you need this MIME type for.

Vaguely remember having this same sort of "PHP's magic wants one thing but the OS has another" problem in the past... Any reason you can't use PHP's built-in magic data?

Have phpMyAdmin running locally and use an SSH tunnel to get access to the MySQL server.

Try giving it the magic.mgc file instead.

You don't have to experiment with anything. Just stop and spend a couple minutes thinking about it logically. 1. All your images are in the same qcic/newsnet/img/posts/ directory. 2. Storing "qcic/newsnet/img/posts/" inside every single row in that one database table is incredibly repetitive. Even moreso the /opt/lampp/htdocs root. You know that all the images are in the one place. 3. Obviously you do have to store something. Why? Because there comes a time when you need to know a URL for a file and you won't know a certain part of it. So what do you need to store? The part of the filename you don't know. 4. If all your images are in the same posts/ directory (as in you're not storing them in additional subdirectories, like putting 610f1962cc3621.48842272.jpeg into /61/0f/610f1962cc3621.48842272.jpeg) then the only part you don't know is the file's name itself. Does that make sense? Did I miss an important fact somewhere in there? After all that, you've now presumably come to the conclusion that all you need in the database table is the plain name, meaning like "610f1962cc3621.48842272.jpeg". So 1. Fix your file uploading code to only store that part of the filename. 2. Whenever you need an <img> reference to that file, have the src be the public path to the upload directory + the filename from the database. If the upload directory is /opt/lampp/htdocs/qcic/newsnet/img/posts and your website is at /opt/lampp/htdocs then the public path is /qcic/newsnet/img/posts. That's all it takes.

Stop worrying about what you're seeing in the browser for a while. If you fix the underlying problems then stuff in the browser will magically start to work. Let's go one step at a time. An image gets uploaded. Because it's a news thing, you want to store it in /opt/lampp/htdocs/news/img/posts/. Is there any reason qcic/usernet/content/add_post.php will want to store the file anywhere else? Does it handle other types of uploads? If so, how does it handle the different types when it comes to where uploaded images go and what database tables get updated?

Uh huh. Have you reached the point where all you're storing is the part of the filename that your code won't already know about?

Stop storing the dumb "/opt/lampp/htdocs" portion in the database and store only the relative path. In fact, if you're talking about a table and column where you know the image is always going to be in /site/news/img/posts then all you have to store is the filename. Or in other words, store only the part of the filename that your code won't already know about.

Either you're going to have to find a way to let us see what "something messy" means, perhaps by giving us a link to the website or by posting some screenshots, or you're going to have to go into much more detail about how "worst" it looks to you.

The request to citruspay.com/payu/icpcheckout returns a 400. It does not say why. You'll have to look at the documentation to find out what was wrong with the form data you submitted. I see a Javascript SDK on GitHub. Are you using it?

Undo doesn't work to go earlier than that new state? As in you can paste text, then make changes and undo those up to the point where you pasted? Looks like the answer is document.execCommand. Deprecated, but seems to be still supported by most browsers, and I haven't found an alternative.

Did you read the part of my post that said what it is you need to do? Not by moving files but by changing the Apache configuration. The key words in there were "document root".

Are you saying that all your URLs are like https://whatever.example.com/public/filename.php? Is that because you have an actual public/ directory for your files? If so then it sounds like you need to tell Apache that your website should have its document root in that very same public/ directory...

Can you tell me what the differences are between those two ideas? How each one behaves?

https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers At least one of those statements in there will be relevant to you.

What date? What step? Compare to what? What test case? ...What? So that's CSV? What does "not working" mean? What does it does? What does it not do? What do you expect to see and what do you actually see? Can you try posting the code again so that it's not all on one line?

Consider what a session is. You give the user a cookie with a unique value, then every time you receive that unique value, you pull up a block of data you stored previously. Different unique values give you different blocks. A cookie identifies a single device, for the most part. That single device then typically identifies a single user, but there are occasional exceptions to this - such as the famous "uncheck on a shared computer" checkbox. As long as you want to store data in that block according to the device or the user then you're probably okay because that session is tied to that device and that user. (There are other kinds of Bad Things you can do with sessions, obviously, but they're another conversation.) If you want to store data in that block according to the webpage they were just on, well that's a problem because the session is not per page. How long has the data been in there? What has the user done in the time after visiting the first page? Storing data per day of the week would also be a problem. What if you access that data on a different day?

The problem with sessions is that things get screwy if people try to do two different things at once. Say, in multiple tabs or windows. So don't use the session for this. Do what GW said: create a unique token for the image, store in the database, then use that token with label.php.

I was pointing out the period, not the variable. Imagine how much harder it will be to fix later. There's a really, really obvious problem here that you have to solve: being extremely careful about what user names you allow. Not only must you require letters and perhaps numbers, you can't allow certain words because it might conflict with other real tables. That suggests this line if($row = mysqli_fetch_assoc($resultdata)){ is happening. Possibly the INSERT is not inserting, which you can check if you paid attention to return values from the mysqli functions, but that tends to be less likely.