requinix

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?

Okay... So basically, that stuff you wrote into the code, you want it to appear just like that in the file? Have you tried forgetting complicated logic about splitting arrays into groups of three and simply writing a string to a file?

Sigh. Keep adding console.log()s in assorted places here and there until you can discover where the underlying problem is. It might be helpful to try logging relevant variables and values instead of just strings so that you don't have to guess at what they are.

Well, okay, I would suggest doing some debugging. You know, like verifying that the onclick function has been assigned and that uploadToServer is executing. If you need tips on how to do that, a simple console.log at relevant location(s) to let you know code has been hit is easy to add.

How much debugging have you done? Verified that the onclick function has been assigned (which is poor practice, by the way)? Is uploadToServer even executing?

You could spend your time looking for a library that "reinvents the wheel", as they say. Or you could install the SOAP extension and get on with the rest of your life. One of those packages should correspond to the particular version of PHP you have installed.

Dude, you're really not helping me here. Try answering my questions in a way that does not repeat the same thing you've said before, okay? I do not want a description of the inputs. I do not want you to talk about "it's a hex color". I don't care whether it's a hex value or a list of animals I can see at my local zoo or how many cups of vanilla extract I have to bake to fill my house with its delicious smell. What I do want is some literal values. I want you to take that variable you said you have, var_dump() it into a webpage or as console output (I said print_r() before but I've changed my mind), and literally copy-and-paste that into a post. For example, if your real code is $file-> File :: WriteFile ( $filepath . $filename, $test ); and $test had that "TEST" stuff you demonstrated, then I would expect your next post to contain, somewhere inside it, string(61) "TEST!, TEST!, TEST!, TEST!, TEST!, TEST!, TEST!, TEST!, TEST!" For bonus points, you could even tell me literally what you want to see saved into the file - again, literally what you want, not a description of it but the exact content of the file - in case I don't understand correctly what you're trying to say about the grouping by 3 or the weird trailing commas or whatever. But anyway, here's the thing. I don't think you have a variable named $test containing that "TEST" stuff. I assume it's either an array or a string, but maybe it isn't, and I assume the array (if it is one) contains multiple values or the string (if it is one) contains multiple comma-separated things inside it (which may or may not constitute a valid CSV line). My problem is that I don't think it's one thing and I do assume it's something else, and that's all I have to go on. And guessing like that does not help me to help you to put the contents of that variable into the file in the way you want it do be done.

I'll try again but even more explicitly. 1. You need to call WriteFile with certain arguments. The first one is the file path and name, great. Now think about the second one. Is it a variable? 2. Take that variable, put a real "value" into it, and print_r() it. What is the output? 3. Given that particular output, exactly what is it that you want to write to the file?

php-soap is the correct name for the official package, however CentOS 7 is a very old version and only supports PHP 5.4. Which means you probably installed another source in order to get a more recent version of PHP. Try a yum search for anything soap and see if the package you need goes by a different name.

If the data is CSV then you need to treat it like CSV data. Because that's what it is. If you try to pretend it is something else then you'll run into problems. It's trivial to take an array with a bunch of things and "group" them into 3s - once you get it into that form. Back to this code: $file-> File :: WriteFile ( $filepath . $filename, "TEST!, TEST!, TEST!, " . "TEST!, TEST!, TEST!, " . "TEST!, TEST!, TEST!" ); I imagine that is not the real code you want to use. What is the real code? The data you're trying to write to the file: what does it actually look like?

This: $file-> File :: WriteFile ( $filepath . $filename, "TEST!, TEST!, TEST!, " . "TEST!, TEST!, TEST!, " . "TEST!, TEST!, TEST!" ); Is that what it has to be? Because you act like you want those three "lines" of TESTs to be three separate strings, but if you concatenate them like that then you only have one string, and splitting them apart into multiple strings again leads to this whole mess about splitting delimiters. You also talk about a multidimensional array, but you don't have that here. You have an array containing one string. And you have code that uses fopen/fclose but does absolutely nothing with them because you actually use file_put_contents. And there's the comment which makes it super obvious that you copy/pasted the code from StackOverflow. So I don't really get the impression that you know what's going on here. And if you don't know then how am I supposed to know? Is the "TEST" string supposed to represent some different string? CSV string, maybe? Is it written in code or pulled from a database or submitted by a user through a form or what? Not asking to be annoying. I'm asking because this whole thing doesn't make any sense, and I can only assume that it's supposed to make sense, so clearly I'm missing something important.

The code behind checkDelimiter and SplitFileByDelimiter is probably going to be relevant here, don't you think?

Composer is a command-line utility, meaning you cannot use it through WHM/cPanel. You need SSH access and a general familiarity with Linux terminals.

@sumon4asad44: Please reply to this thread with an email address or other external contact method for someone to reach you about this work.

Browsers may throttle background activity when users are not active on the page. Switch to WebSockets instead of AJAX polling.