requinix

- The form is definitely not submitted as a field. Ever. A named form is only useful through Javascript's `document.forms` collection. - A named submit button is always submitted if that button was used to trigger the submission. That includes clicking it and hitting Enter in most inputs (the first submit button listed in the markup is the one used). Forms serialized through jQuery do not include any buttons, even if the code is running because a button was clicked. - The code in the first post is incorrect. I don't mean about best practices or security or whatever. It has flaws that were clearly not intended or supposed to be there. Not sure if it was going to be rewritten anyways.

And he's right. But what he may have neglected to mention is that adding the 'i' is not enough. Check out the documentation Barand linked to.

Was the code using the mysql_* functions previously? And someone found out they needed to upgrade to the mysqli_* functions? Did they think it was just a matter of adding an 'i' in the function names? If it was and they did, they're wrong: it's almost just a matter of adding the 'i'.

That was mostly a rhetorical question. I'll rephrase: mod_xsendfile does not support sending multiple files by any way of specifying multiple paths.

Okay.

Send the JSON to a PHP script on the server using AJAX. The script decodes the JSON, verifies it looks good according to whatever criteria you haven't mentioned are important for this JSON, and then encodes and saves.

Notion, is this another one of your famous unnecessarily abstract questions? Using it to get generic answers to a specific problem?

Divide by 100... divide by 100,000... that means the next one will be divide by 100,000,000?

Is there a difference?

I said that a few days ago. Have you done it? Have you made it so that /article?title=this-is-new-product works?

No, it does not support multiple files.

There's a lot more to cache than just the data itself. Does your 11GB count indexes? It definitely won't include a query cache.

I'm not sure I understand. You posted some code earlier and asked why it didn't work, and are now saying that this other code is somehow responsible for it? Look at your code again, but this time with proper indentation: $_SESSION["cart_item"] = array( // <- this will be $cart_items 'cart_item' => array( // <- so this is what the foreach will find 'id' => $id, 'product_name' => $product_name ) );

The item in $_SESSION is called "cart_item". One item. That's what it is, right? You then assign it to a variable named "cart_items". Plural. That does not magically make it have multiple items. You only have the one item. You can't foreach over an item. What you need is an array of items (see the plural?) which you can then foreach over.

That adds a .php extension. I'm asking what you have for this clean URL stuff you want to do.

I don't mean to replace your network_id key with this. Keep it with its CASCADE SET NULL. And the account_id key. Add a new key, with no cascading options, that is specifically about enforcing the account_id agrees with the (if present) network_id. You have to delete the attachment too, otherwise IPB will think you want them added automatically.

Oh, so the node's network_id is not so much "child of" but more "assigned to". That's fine. MySQL's foreign keys are always MATCH SIMPLE, meaning that any value can be NULL and the key just won't be enforced. So give the node a foreign key (network_id, account_id) to network's (id, account_id).

PHP scripts aren't programs. They don't execute themselves. They are interpreted. Which means how they're interpreted depends on what is doing the interpreting.

"Added back"? That doesn't sound right. The network ID should be artificial, so if you "add back" the network then it will have a new ID. So either, a) The network ID is not artificial. It should be some unique identifier inherent to the network. I have no idea what that might be, but it would be something you can recover when you restore the deleted network. b) Don't delete networks. Mark them as deleted but leave the data intact. Then you can unmark it later.

No, because a decent "script" doesn't know you or your application or your server. Perish the thought but you have to actually do some work here.

Yeah. Javascript runs on the browser. Not the server. (Except like Node.js, that's different.) And it would be an extremely terrible idea to allow Javascript on someone's browser to upload files to your server without your say-so.

Then the answer to "where is the line I need to edit" is either "whatever the code says the line is" or "whatever the documentation says the line is". In other words, I don't see what one has to do with the other. Javascript cannot upload files to a directory on your server. Thankfully. You have to have an script to receive uploaded files and process them according to however you want.

Exactly what kind of answer are you looking for? How can anyone reply to that question in a way that doesn't make the answer sound obvious?

One sure-fire way to get people to not help you is to tag them and plead for their help. What RewriteRule have you tried to do this? "Can't" do that with just mod_rewrite. The problem is that you want to replace spaces with hyphens. What you can do is rewrite /article/this-is-new-product to /article?title=this-is-new-product. So first make your article.php support that. When that's ready, What RewriteRule have you tried to do this?

Not upscale the whole image - just the parts that involve rendering text. Scale up, add text and draw stuff, scale down, layer on images and whatever other assets. And GD does support transparency, but it's a bit tricky to get working. All in all ImageMagick is just generally better quality. GD is more about quick and dirty.