requinix

That will not work for the same reason that I cannot sit down at your computer and do this work for you: I am over here and you are over there and neither of us can see what the other is doing.

You have two options: 1. Use hidden inputs, like I said to do, so that the user can do whatever they want. I don't know what else they can do with the table. If anything - every single bit of information you've decided to reveal so far I've had to forcibly pry out of you and I'm not going to do that anymore. They do whatever with the table and cells, you use AJAX to send the current state of the form's "data" to PHP. 2. Don't bother with the hidden inputs because the user can't change anything once they hit whatever button. You have code that builds the table cells so it would be easy to (for example) insert those shadeHex values into an array as you go, then when the table is done you can AJAX that array to PHP. Either way, the point is you are sending data to PHP rather than having it try to go out and get the data on its own (which isn't actually possible to do in this case anyways).

Yeah, okay, that's the exact opposite of what I thought you wanted to do. Put the table into a <form> and use hidden inputs to identify each value. $ ( "#shades" ).append ( '<tr>' + '<td class="hexcolor">' + '<a style="background : ' + shadeHex + '"></a>' + '</td>' + '<td class="hexcode">' + '<input type="hidden" name="shade[]" value="' + shadeHex or whatever + '">' + shadeHex + '</td>' + '</tr>' ); Submit the form normally or with AJAX and you'll have an array of shadeHex (or whatever) values.

Okay... so if the table changes according to how the user interacts with the page, and you first said that you wanted PHP to get those values from the table, then how is PHP supposed to know how the user interacted with it? Is your question more about how to send the values from the table to PHP? Maybe the user did something and now you want the results of whatever to be handled by some PHP code? If that's the case then exactly what is the information you want? What is the user doing, anyway? And one more thing. If you haven't noticed, posting little bits here and there just means I have to keep asking more and more questions...

There has to be more than that - where are "shades" and "tints" coming from? And is there a particular reason this is all being done with Javascript? Is the user interacting with the page to change what values are being shown in the table?

Alright, we'll do this one step at a time. The shadeHex values. Where are those coming from?

I would do it the way I literally just said: by examining and reusing/adapting the code that index.php is currently using to get the data.

You're trying to grab data from your own site. You have some PHP code responsible for outputting data into the table, right? Don't you think it would be easier to mimic that code that gets the data rather than do this complicated thing of executing the PHP, parsing the HTML, locating the correct table somewhere inside it, and extracting parts from it?

$stream = fopen ( "index.php", "r" ); Are you trying to read an HTML table that's outputted by a page on your own site?

Don't even consider operating system users. Should have absolutely nothing to do with the people on your website. Users should have some sort of account on your site before they get a token. If they didn't then how would you know which token corresponds to which user? If you have a framework and it provides authentication then you should use that. If not then you can't really do that, can you? Do you want simple or do you want secure?

Can I assume you mean that you use POST when performing certain operations, such as when someone wants to add inventory to the site, and that you use regular GET when it comes to simple browsing? Because it doesn't sound like that's the case. And it should be.

If title.php is the only place that knows what the new title needs to be then you'll have to make an AJAX request to it.

You were frustrated. I knew you could get the answer on your own with a little prodding, but if I didn't prod hard enough then you might just get upset at me stringing you along. So I figured a long post you had to read through that explained, but yes ultimately gave away (kinda), the answer was a decent middle-ground.

Undo everything you installed manually, reinstall through apt. Ubuntu 20 supports PHP 7.4 so you should be fine.

Too many people are obsessed with "filtering" bad inputs. You don't have to "filter" anything. You don't have to remove HTML tags. You don't have to remove SQL keywords. You don't have to strip quotes or backslashes. All you have to do is make sure that whatever the user typed doesn't screw around with what you're trying to do. Want to put it into HTML? Make sure it doesn't screw around with your HTML. Want to put it into SQL? Make sure it doesn't screw around with your SQL. Want to send it in JSON? Make sure it doesn't screw around with your JSON. And every single one of those situations has a simple, single best-practice solution: HTML? Use htmlspecialchars with ENT_QUOTES* and the correct charset. SQL? Use prepared statements. JSON? Use json_encode. That's it. No filter_vars or filter_inputs, no strip_tags, no regular expressions, nothing stupid like that. User wants to look cool and type <script> tags into their forum post? Go ahead and let them, because it'll just show up as plain and simple text. Like it just did now. * Only actually required if you are putting the input into an single quote-delimited tag attribute. Using double quotes for your attributes? Not outputting into an HTML tag? Then you don't technically need ENT_QUOTES.

The answer is yes. It's a one-liner. It's crazy simple too. And I think that you can figure it out for yourself if only you were willing to think about what it is you're trying to do using a different mindset. Because contrary to what you might think, this is not tech support. This is a learning experience. If you're willing to make use of it. You start with a string "11111X ,,, ,222X , abcd ,,,,,,,33333X". You care about non-digits and non-Xs, which means [^\dX]. That also includes commas too. If you replace each [^\dX] with a comma you get "11111X,,,,,,,,222X,,,,,abcd,,,,,,,,33333X" Now you have a bunch of commas. What's not obvious there is that the regex also replaced each comma with another comma. No change, of course, but the important part is that the very simple [^\dX] is already looking at them. You now think "damn, I have a lot of commas, I need to condense them all down to just one". If you did another separate regex to substitute ,+ into , then that would definitely take care of it, but here's the thing: (a) your original [^\dX] was already looking at the commas and (b) your own regex was producing some of those commas that you don't actually want. Sure doesn't make sense to use a second regex when (a) yours is already processing those bad commas and (b) it's outputting stuff you don't even like. Still remember how [^\dX] includes commas? If you're turning [^\dX] into , and you want to replace ,+ with , then you could simply combine those together to do both actions at the same time. Right? Which results in replacing [^\dX]+ with , But what will that do on the input string? 1. "11111X" is good and gets skipped over 2. " ,,, ," is all matched by [^\dX]+ and gets replaced with a single comma 3. "222X" is also good and skipped over 4. " , abcd ,,,,,,," is all matched too and gets replaced with a single comma 5. "33333X" is good and skipped That leaves you with "11111X" + one comma + "222X" + one comma + "33333X".

There's an easier approach if you think about it in a slightly different way. You want to replace non-digits (besides X) with a comma. If there are multiple consecutive non-digits then they'll be replaced with multiple consecutive commas. You also want to replace multiple consecutive commas with one single comma. Do you see the repetition in there? Multiple non-digits become multiple commas become one comma. You could skip that whole middle step and go straight from multiple non-digits to a single comma. Then what about multiple commas. Well, a comma counts as a "non-digit", doesn't it?

So I strongly suggest that if you're going to maintain someone's code then you should really become familiar with the basics of programming. Learn about what variables are and where their values come from and how they get used. Spending a few hours going through some tutorials should be enough to grasp most of the basics, especially if you have some code you can look at and run to see how it works, but trying your hand with a couple simple applications (and more than just Hello World, such as a number guessing game) will help too. When you understand more about variables and what happens to them as PHP goes through your code will hopefully make it much easier to understand what your code here is doing. Because while I can read and understand the code, I'm not the one who has to maintain it.

Back to one of the questions I asked earlier: are you sure PHP is running from the correct location? Does glob/scandir/ls without any path information include encrypt.jar? Are file permissions correct such that Apache and/or PHP can properly access the file? In other words, does var_dump(is_readable("encrypt.jar")); output true?

Stuff does not simply "suddenly stop working". Find out what's changed recently: maybe someone reconfigured PHP, maybe they upgraded versions, maybe they altered how Apache runs, whatever.

Looks like you're on shared hosting. Contact your host to see if you can get that restriction lifted, but don't hold your breath.

What does var_dump($output); show? Any errors in the error log? Add error_reporting(-1); ini_set("display_errors", true); at the top of the file and try again.

If you need to write other hex codes to the file, what are you going to do? Add them to your list in the code? Basically, what I'm saying is, if you have this code now <?php include_once ( 'includes/file-mainframe.php' ); $file -> WriteFile ( $filepath . $filename, [ "ff00ff", "ff00cc", "ff0099", "ff0066", "ff0033", "ff0000", "ff3300", "ff6600", "ff9900", "ffcc00", "ffff00", "ccff00", "99ff00", "66ff00", "33ff00", "00ff00", "00ff33", "00ff66", "00ff99", "00ffcc", "00ffff", "00ccff", "0099ff", "0066ff", "0033ff", "0000ff", "3300ff", "6600ff", "9900ff", "cc00ff", "9900ff", "6600ff", "3300ff", "0000ff", "0033ff", "0066ff", "0099ff", "00ccff", "00ffff", "00ffcc", "00ff99", "00ff66", "00ff33", "00ff00", "33ff00", "66ff00", "99ff00", "ccff00", "ffff00", "ffcc00", "ff9900", "ff6600", "ff3300", "ff0000", "ff0033", "ff0066", "ff0099", "ff00cc", "ff00ff" ] ); then why not simply turn it into <?php include_once ( 'includes/file-mainframe.php' ); file_put_contents ( $filepath . $filename, <<<STRING "ff00ff", "ff00cc", "ff0099", "ff0066", "ff0033", "ff0000", "ff3300", "ff6600", "ff9900", "ffcc00", "ffff00", "ccff00", "99ff00", "66ff00", "33ff00", "00ff00", "00ff33", "00ff66", "00ff99", "00ffcc", "00ffff", "00ccff", "0099ff", "0066ff", "0033ff", "0000ff", "3300ff", "6600ff", "9900ff", "cc00ff", "9900ff", "6600ff", "3300ff", "0000ff", "0033ff", "0066ff", "0099ff", "00ccff", "00ffff", "00ffcc", "00ff99", "00ff66", "00ff33", "00ff00", "33ff00", "66ff00", "99ff00", "ccff00", "ffff00", "ffcc00", "ff9900", "ff6600", "ff3300", "ff0000", "ff0033", "ff0066", "ff0099", "ff00cc", "ff00ff" STRING ); and there you go: written to the file exactly the way you want by virtue of the fact that you told PHP to write it to the file exactly the way you want.

No. Do the other troubleshooting steps first. If it turns out that the answer is that exec() is disabled then we can deal with that. Because that is probably not the problem.

Is exec() enabled? Can you run other commands? Simple commands? Is the command exactly what you think it is? You've confirmed $data and $privateKey have the values you think they have? Are you executing this from the right directory? Do commands like is_file() think that "encrypt.jar" exists where you expect?