requinix

PHP executes in the order you tell it to. If you want the output to appear on a certain spot on the page then you need code at that spot which causes the output. Could simply be a matter of moving the include statement, but like benanamen said you should post your code.

This code has absolutely nothing to do with databases or PDO.

I suspect doing that will try to interpret existing data as YYYYMMDDHHMMSS strings, not as Unix timestamps. Will definitely work: add the created_at column, UPDATE it using FROM_UNIXTIME(user_date), then drop user_date. Three statements.

Still doesn't help. 1. Where does the transaction processing happen? Does it happen earlier and set $payment? It has to or else you can't use $payment. 2. According to the earlier code, isApproved is a function that you need to call. Not a simple property. 3. Are you actually storing credit card information in your database like that? Do you know what kinds of laws you're breaking? I hope this payment stuff means you don't have to do that anymore, and that once it's deployed you'll purge all data in those two database tables. And lastly, 4. Have you tried executing any of this? (If so, any specific problems or errors you're trying to address?) Or are you still working on writing the code?

Syntactically it's correct. But you've only posted a couple chunks of code with no context. Where is the first code located? When is it executing? Where is the second and when does it execute? It's impossible to tell whether the code is correct without that kind of information. How about posting the entirety of edit.php?

As the output shows the first layer of the "JSON" is an array with a numeric key. That suggests it could contain more than one element. Is that possible? If so, what will you do with the multiple items in the array? Ultimately you will have the second array. From there it's either ->name or ->live->stream->name. Assuming you are still decoding as an object, as the output shows it using arrays instead.

What do you mean by that? I don't see anything triangular.

You aren't repeating that character set at the end. As for the format, [0] will always be the full match. Best you can get is "i" as [1] and the identifier as [2] by using what you have now with the PREG_SET_ORDER flag.

Plain HTML does not support submitting forms using links. You have two options: a) Use a form button ( or ) and style it like the way you want. It is possible and not much more work to do since you have the appearance already working for a link. b) Put an onclick handler on the link and cause it to submit the form. This isn't AJAX but it does require Javascript. The first option is much better than the second.

If that $Variable thing was your actual problem then I would say If that's not your actual problem, what is?

Working on it.

As far as we knew it was down for good. It just happened that there were things going on we weren't aware of that gave it a second life.

We can't really share what's been told to us about any plans for the site. Regardless, consider that all this transition stuff only just recently happened and we're still getting back on our feet.

Have you tried looking at the documentation? Dates and times don't even have lengths. The string values do, sure, but the data type itself doesn't. Lengths only matter on field types that (can) have variable length data. Like strings and numbers: for VARCHARs it is the maximum character length stored, while for *INTs it is only the display width.

You can't do that in Javascript: pow(2, 3200) is 19769064789825639936542264398379633403153906826257738289182657101583406010939511 26756295848974613063099294244703164628428967968057547050608904859234600159014229 32910219510157408105706166194810688480032112981869391460884528166146233381432654 43897411640093676025481038827241878315873949544631831377356573070196373591692908 34318700453890617892714561362370427388384101316010134426924662084888461376218489 65379424299905389115138246588848200330008567611017346799700349415983009427194750 60249742719534147060380682101703389616632028392036411208652632922487186929249151 89291455200665479606951612257868495299167071771306894428954788679149900427954823 30039364000764939774210663557382842575273030537523272133980387188929928113420821 11313410011356054468094774099792796272131886101128679295697894926404657366339250 65052540962862027736312499143902692033755536952046162410311395501619568814547777 27103125924797325086658311685361590835288130558729717818314538874578129700223818 1376Maybe that part is a typo?

Always use quotes with HTML attributes. But your two versions with quotes are also adding spaces that shouldn't be there: "......"is going to produce

Those three variables are what you need. You just have to do something with them. Well, one correction. They're objects. Go with $name = (string)$spotter['name']; $lat = (string)$spotter['lat']; $long = (string)$spotter['lng'];

Looks fine so far. Except that $spotter is an object so you can't merely echo it.

Stop using addslashes. Use htmlspecialchars. Post your PHP code if you don't understand.

If you do a WHOIS lookup on one of those IP addresses then you'll see they all belong to one CIDR (IP address range) block: 52.32.0.0/11, which translates to 52.32.0.0 - 52.63.255.255. While whoever is running the servers could change their IP address at basically any time, they'll still end up with something in that range. Probably.

Do you know that the new users' emails are unique? They don't already exist in the database you're inserting into? If that is true then you can do this an easier way: do one mass INSERT...SELECT into the user table with the new user records, then do four more INSERT...SELECT queries where you JOIN in the new and old user tables to get the user IDs. (If that's not true then you need to resolve that regardless, but it doesn't make this much more complicated. A temporary table of just the new users would be a really quick solution.) Example? Here's the user table after you insert the new records. -- INSERT INTO users (email, username) SELECT email, username FROM old_users id | email | username ---+-------------------+--------- 1 | alice@example.com | Alice <- existing 2 | bob@example.com | Bob <- existing 7 | cindy@example.com | Cindy <- new 8 | david@example.com | David <- new7 and 8 are new. Here's the profiles table before adding new records. user_id | name | age --------+-------------+---- 1 | Alice Baker | 19 2 | Bob Smith | 25The query to add to it: INSERT INTO profiles (user_id, name, age) SELECT u.id, op.name, op.age FROM old_profiles op /* old profile data */ JOIN old_users ou ON op.user_id = ou.id /* get the email address to look up the new user record */ JOIN users u ON ou.email = u.email /* new user record has the new user ID */

That's the code where you generate the dates. Apparently that's working? The dates themselves are right? So where's the code where you display the attendance table?

You got the replacement part done right, but all you're doing is grabbing the current value and sticking the modified value into a variable. Nothing else. Want to fix the values with Javascript? (Why can't you fix it server-side?) Fix all of them, and do it when the page loads. $(function() { $("#model option").each(function() { this.value = this.value.replace(/\s+/g, "-"); }); });

Alright, I think I see a workaround: don't use Phar for the compression. It doesn't seem to clean up temporary files if you've enabled compression? Wouldn't expect it to use temp files in the first place... Instead use it to write out the tar archive and compress it yourself manually, such as by using one of: `gzip {$tar_file}`; // creates $tar_file.gz $in = fopen($tar_file, "rb"); $out = fopen("compress.zlib://{$tar_file}.gz", "wb"); // name.tar.gz; use a combination of dirname and basename to get just name.tgz stream_copy_to_stream($in, $out); fclose($out); fclose($in);

Hmm. Report it as abuse to Amazon, then block the IP range (52.32.0.0/11).