requinix

Worry about "clean" and "minimal" once you have stuff that works, first.

You mentioned AJAX in the title so... how about that?

Take a look at Proxy.

On the screen as people are taking the video? I would be very surprised if that was possible. If you need to tell them something, do so on the page before they activate the control.

Once it's installed, sure. But it's not installed by default.

If you need something simple to test a simple site then you can use PHP's built-in server. If you need something more complicated then you're going to have to spend disk space to get it. If you don't need a database then you can install Apache/nginx on its own - if you don't mind configuring them yourself. No? But it is available to install - at least in Pro, not sure about Home.

Apache and PHP do not want to own files. They want to be able to read files, and just like books from a library, they do not have to own the files to be able to read them. For the shared server, you need to find out whether PHP runs as its own user or as your same user account. You must answer this with a webpage, not from a login shell: a webpage that echo exec("whoami"), or uses phpinfo(), or some other method. If PHP runs as the same user as your own account: - All files and directories should be owned by your user account and group - File permissions should be 0640 or 0644 - Directory permissions should be 0750 or 0755 - If you need to support file uploads, nothing special has to be done. Do not use 0777 permissions. If PHP runs as a different user from your own account, such as "www-data": - All files and directories should be owned by your user account and group - File permissions should be 0644 - Directory permissions should be 0755 - If you need to support file uploads: create a special directory for the files (such as "uploads") and set permissions 0777. For your own server, if you want it to have the same website as the shared server then you should make it use the same Apache + PHP setup (mod_php or php-fpm) and with a different user from your regular account (such as "www-data"). Using the same setup is a good way to know that what works on this server will also work on the shared server.

"Won't post" isn't a particularly helpful description. What have you done to troubleshoot this yourself so far? Checked for error messages? Spam folders? Tried using different email accounts, both for sending as well as receiving?

When you log in as a user and then ask the system who you are, it will tell you that you are the user you logged in as. I'm not talking about shell access. I'm talking about PHP when it runs on your website. You have root/sudo access on a shared hosting server? Are you sure it's a shared hosting server? As in there are multiple people with access to the same server your site is on? PHP the application. If your setup uses mod_php then PHP runs as whatever user Apache runs as. If your setup uses php-fpm then PHP runs as whatever user php-fpm is set to run as. That's... not the right thing to do. If you set up the server yourself then you are not, in fact, on a shared hosting server, and therefore most of what I said was a waste of your and my time. And they're right in this situation. And by "right" I mean "wrong". There's basically no reason to put yourself in the www-data group, like, ever. Okay, now I'm confused. Are you running your website on a shared hosting server or not? I don't care about what you're doing locally or on a test server or whatever. I mean, the place where your website is running, is it "shared hosting"? The first guy is wrong. The second guy is mostly right because "you can't even write files to your own server" is partly what you actually want to be the case. Like I said in my first reply, it depends. Primarily on dedicated vs. shared hosting. Just like how the question "how do I put my car in reverse?" sounds really simple but actually has multiple different-but-similar answers.

One is Javascript, one is not. Does what you have now work? Is there anything that says it's obsolete or deprecated? If not then keep using it.

This is a link to the page. The link does not matter once you arrive on that page. If you want to do something with that page then the link to the page is not where you should be focusing your efforts. If the scraping is all done in PHP and there is no output of any kind (or you can remove all of the output already there) then all you have to do is use a header() redirect at the end of the script.

For both questions it depends on the server setup. Even with shared hosting there are multiple approaches. The questions you need answers to are: 1. What user is PHP running as? 2. What group is PHP running as? 3. Do you have a personal "billybob" group too? (Probably.) 4. What other groups do your user account belong to? On shared hosting, it's somewhat common for PHP to run under your own user account. It has exactly the same access to files and directories as you do. It sounds like that is the setup you have. If that's the case then there isn't much point messing around with permissions: you and PHP are the same user so it doesn't matter what group you assign. In fact, it's quite possible that by changing group ownership to www-data you're creating a problem, because if your account is also in the www-data group then that means other users on the server are probably also in the www-data group, and changing group ownership away from your own personal group you've decreased security. But that could easily not be true - I think it would be weird and unlikely that you are a member of www-data, but if you aren't then I don't know how you changed group ownership to it...

What's happening behind the scenes is a matter of 32-bit versus 64-bit integers. You know how everything is 64-bit now, right? That's kinda true. Signed (=capable of representing positive and negative values) 32-bit integers are limited to +/- 2.1 billion. If each of those is 1 second and you start counting from January 1970 then that stops sometime in January 2038. A lot of software is still 32-bit, but less and less each year. Signed 64-bit integers are limited to... well, a very large number in the unfathomably-distant future - which is to say, as far as timestamps are concerned, it's effectively unlimited. Unless you want to try to count sub-second intervals, in which case it's slightly less than but still more or less unlimited. For a simpler example, consider Y2K. If you represent years as just 00-99 then December 1999 ends with you starting January 1900. The best solution to that is to use more digits: four digits means you can tell the difference between 1900 and 2000, just like how with 64-bit numbers you could tell the difference between Jan 1st 1970 (0) and Feb 7th 2106 (2^32). Regarding PHP, it's been 64-bit for a very long time, except on Windows when it's only been available since PHP 7.0 (which most people would also count as "a very long time"). But Y2K38 is still a thing.

PHP won't try to guess your timezone. Tell it explicitly what you want with date.timezone. Like realistically, how often are you moving servers?

No. Using eval is a really bad idea. There are always better solutions to problems than using eval. $num is the only unknown part, right? Look at this: $gm = array( 9 => array( "hodds" => $games[53]["BP"], "aodds" => $games[52]["BP"] ) ); echo $gm[$num]["hodds"]; Really easy.

If you want to submit the form and redirect then you cannot do it with any Javascript or other alterations to the button itself. Has to be PHP. What is the code that handles the form submission?

Have you looked at the HTML source of the page? To confirm that the links really are not being outputted, as opposed to some CSS issue that's hiding them from you?

What?

Almost: 4.19 * first 75 units (314.25) + 5.72 * next 92 units (526.24) + 30 flat charge = 870.49, +5% VAT = 914.01

Did you mark your own post as being "the solution" because you figured out the answer yourself? Or are you still having problems?

Most "hacks" are people gaining access to a database by way of SQL injection. Encryption would help because they can't get the encryption key - just the data. Of course the problem with encryption is that if you lose your key then you lose everything. Irrevocably. Plus the obvious drawbacks of having to encrypt and decrypt stuff all the time. Shared hosting is itself a risk, too. Can you move off it? Besides the dedicated environment being more secure, you can also mitigate SQL injection attacks by moving the database off to another server - one not exposed to the internet - and on this same server you also put a simple webservice that gets and stores customer data. Essentially, you make API calls to yourself when you need that data.

No. You can't see the forest for the trees. This is a really, really basic and fundamental question about what files are and what file_get_contents does. The kind of thing that I would expect you to know the answer to, if not for the fact that you're in up to your neck in something you don't understand.

With ^([^/]*)$ then /vojvodjanski.html -> index.php?c=vokvodjanski.html 1. Make the .html optional so that /vojvodjanski.html will continue to work and you do not create 404 errors for old URLs that are still being used. 2. Make the last [^/]* -> [^/]*? because * will match "everything" but *? will match "until". RewriteRule ^([^/]*?)(\.html)?$ /index.php?c=$1 [L] 3. You must change the URLs on your site to not use .html. Because mod_rewrite will not change your website for you. <a href="/vojvodjanski">

RewriteRule ^(hu)/([^/]*)\.html$ /index.php?lg=$1&c=$2 [L] This URL is very similar to the /vojvodjanski/drustvo.html because they are both "/" + word #1 + "/" + word #2 + ".html". If you want word #1 "hu" to be special then you must put this RewriteRule before the [^/]+/[^/]+.html RewriteRule. If you want another language, like sk, then RewriteRule ^(hu|sk)/([^/]*)\.html$ /index.php?lg=$1&c=$2 [L]

I don't know how any of that would help - at least not in an automated way. If you want to remove "hidden scripting" then use an image processing library that can deal with the image and strip out everything else that doesn't matter. However that doesn't eliminate the possibility of someone going through a whole lot of effort to create a plain image whose compressed data contains a malicious string. If that's even possible to do. You cannot protect yourself against everything. You can protect yourself against things that actually matter.