dalecosp

+1 for a development environment. I use Oracle's Virtualbox and install a BSD-family OS with Apache+PHP ... you might be able to even find a Docker container or something like that for free out there someplace. As far as what will happen, the biggest recent changes to PHP, in terms of effect, at our company were removing the old mysql_* stuff (although most of it was long gone, we found out that some infrequently-used LAN software and reports still had some mysql_* stuff in them, and the removal of mcrypt().

Drag 'n drop is done with an AJAX system; a JavaScript front-end script packages the image data into a FormData object, and the AJAX operation will POST that to a PHP handler script on the server, which then does the work to put it someplace just like we did in the Elder Days when we used a basic upload form in HTML. So, at the very least you need two scripts, one PHP and one in JS.

It would also be possible to post-process all the URLs on the page with JavaScript, but who wants to take time to do THAT?

Pretty URLs are fairly simple. Either use mod_rewrite (for Apache servers) or its equivalent on your system to do the complete work, or use it to redirect to a centralized script that reads the URL parameters and shows content based on that parameter. At work, we have listings like: www.ombe.com/listing/2151404/Uninet-Developer-for-use-in-Ricoh-Aficio-200,-250,-345g mod_rewrite has this rule: RewriteRule ^listing/([0-9]+)/?.*$ listing?$1 [NC,L] "Listing" does something like this: $product_num = intval($_SERVER['QUERY_STRING']); Of course there's a LOT more, config and security modules before this point, and error handling for invalid query strings, and so on.

The quid pro quos of going to "MySQLI" include changing your connection string and the query syntax. The one big "gotcha" to me when converting old to new (MySQL to MySQLI) was the lack of a mysqli_result() function in the older days, but now you can do something like this: $data = $result->fetch_row()[0]; ... which seems fairly handy to me in place of mysql_result. I'm not sure when this syntax became valid, off the top of my head. PDO is generally touted as great for security and portability. I'm not totally convinced, but the use of prepared statements is preferable to its alternative. I had written quite a bit more here, but I think at this point a good read or two would be in order. I'm not sure there's any 'one size fits all' answer to this issue. This is a thoughtful and well-informed take on the subject. The Reddit comments on it are also kind of interesting. SitePoint discussion. Jim Westergren tested, and prefers, PDO with ATTR_EMULATE_PREPARES. Quora seems to prefer PDO, but there's some really bad info on this page also. I've been in your shoes, and our management wanted quick-n-dirty. I modified everything to MySQLI with a few search/replace operations in the IDE, adapting the connection code, and replacing calls to mysqli_result(). Took very little time at all. If they preferred PDO for security and portability, I would've done that. though.

an indented block ?

There are three echo() constructs that would produce output. A fourth such construct is commented out so it won't run. echo $data[$j]; echo ","; echo "<br>"; If you'd like a space after the comma, add a space after the comma in the 2nd echo shown above. If you're viewing this program's output in a browser, the "<br>" should produce a lineBReak. If you're not, it will just be so much garbledy-gook. Probably this line: //echo "n" Was actually mean to write a 'newline', like this: echo "\n"; Enabling (uncommenting) that line (with the change as shown) would produce a linebreak in console/non-browser output. The whole thing could be one-lined (including an additional space as I mentioned) thusly: echo $data[$j] . ", <br>\n";

Just for additional info, MySQL's max_connection variable has a lower limit of 1 and a max limit of 100000, and the default value for all recent versions of MySQL is 151. We run max_connections=250 on a VM that hosts 4 sites with moderate traffic and about 60 more that get very little. We occasionally have "too many connections" errors, generally when some bot comes by that doesn't read Robots.txt (or a new one that we've haven't added there).

Instead of just dumping mysqli_error(), also dump the statement you tried to make. See if you can see why it wouldn't work. If necessary, try it against a test database.

<?php $foo = "Foobar"; echo "$foo"; // Foobar. echo $foo; // Foobar. Functionally equivalent to above, no quotes needed. echo '$foo'; // $foo. A literal string, and not what we wanted. $foo = "/home/dalecosp/php"; file_put_contents($foo . "/" . 'bar', "This is file content"); // writes the given sentence into /home/dalecosp/php/bar. file_put_contents("$foo/" . "bar", "This is file content"); // does the same thing; because of double-quote variable interpolation, the trailing slash is added to /home/dalecosp/php (it was not given when $foo was assigned). file_put_contents("$foo" . "/bar", "This is file content"); // does the same thing. The slash is still in the string. file_put_contents("$foo/" . '/bar', "This is file content"); // does the same thing, because we literally want '/bar' to be appended to the path given by $foo. file_put_contents('$foo' . '/bar', "This is file content"); // will almost certainly fail, "no such directory $foo/bar". Single quotes are a literal string. Double quotes do variable interpolation. They aren't needed if the variable is all that's required; it's an easy way to concatenate strings or insert a variable into a string.

Welcome to PHPFreaks! There sure are some around here.

Google Translate works for me! (For some subset of languages we're interested in, that is....)

Goodness gracious, great balls of AJAX! What in God's green earth are you selling? Because if it's not blow, crypto-currency or heavily-discounted precious metals ain't no one got time to load a page with one data item on it.

That might be worth a try. You'd have to be careful about where you put your labels ....

Sounds an interesting use case. All in the same folder? 'Cause if the path is different, "config.php" (or 'myApp.ini' or something similar) at least has the distinction of being an appropriate name for a configuration file. I once created 65 sites in one day using logic files, templates, and a config munger that changed "config.php" to contain appropriate defaults for the DOCROOT they were in. One of my proud "not proud" moments, I guess. ??