If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

Where the problem exists is that while I can populate some array with all 50 PM's when my script first runs (e.g. $testArray), when the user submits the Form, any values in my array get erased.

Thats because the script has stopped running and it's variables are lost (thats the way PHP works I'm afraid - not the same as a windows program). When you submit the form the script runs as a fresh instance with its own memory and variables. Thats the way PHP works and why most people use sessions between scripts being executed to store temporary memory.

Originally Posted by doubledee

So I figured that if I could pass the entire array back via the $_POST array, then I could continue to use $testArray, and use all 50 values in it to run my UPDATE and thus mark all 50 PM's as "Unread", if you follow me?!

Yes I've followed that all along and yes there is nothing wrong with doing it that way if thats the way you're happy with it. We've shown you several suitable ways for you to achieve that, it's just a case of you picking what you think is best for you.

Originally Posted by AndrewGSW

I assume you are referring to JS stringify() and parse()?

No I was talking about the php functions. I don't do front end design or javascript

Originally Posted by AndrewGSW

Serializing in PHP is intended to serialize objects..?

Actually I wasn't aware that you could serialize objects. As far as I was aware it only applied to variables such as arrays, strings, numbers etc so thats news to me!

I assume you are referring to JS stringify() and parse()? Serializing in PHP is intended to serialize objects..? Added: to pass a simple array of ids (integers) as a string I would prefer implode() and explode() which have less overhead than serialize().

If passing OOP objects between pages you are likely to store them as serialized session data, as indicated by tangoforce's recent post.

@Andrew: Library is closing. Hope to be back in maybe 20 minutes from somewhere else.

In the mean time, can you please explain more about using Implode/Explode versus Serialize/Unserialize and how I'd go about that?

All of this is quite overwhelming for a newbie like me?!

I can say, though, that "Yes", all I am trying to pass back to my same script is a listing of all MessageID's in the InBox, so my script can UPDATE all Messages in the Inbox (versus individual Messages that may have been "cherry-picked".)

I'm not sure what is the best way to do that, but as you can see, I figured I'd just pass an array in the $_POST?!

(Here is where maybe you more seasoned developers can show me the *best* way to do this using my Procedural Coding.)

Back in a few...

@Debbie HIDDEN only means hidden from view on the page - it is completely visible/accessible when posted to PHP.

Oh, okay. It just leaves me feeling like it is too exposed or something?!

Personally I recommend going with Andys explode/implode as it's simpler. Using the serialisation would make it a bit more complex but it would be slightly (though still possible) for anyone to change those values.

Personally I recommend going with Andys explode/implode as it's simpler. Using the serialisation would make it a bit more complex but it would be slightly (though still possible) for anyone to change those values.

But technically that is true of anything passed through a Form, right?

Since I am just passing back a listing of all PM ID's to the same script so it knows which Messages need to be updated, and since the "pmID" is an Integer, then as long as I sanitize things by casting to an Integer, and using Prepared Statements - which is actually the only way I know how to do database stuff - then I assume that I will be okay from a security standpoint?!

BTW, you guys please don't leave me just yet.

I need to re-read everyone's suggestions, and also go to the PHP Manual and read up on all of this, and then try and piece it all together into a working script?!

But technically that is true of anything passed through a Form, right?

Yes it is. Thats why you need to do your checks at your end.

Originally Posted by doubledee

Since I am just passing back a listing of all PM ID's to the same script so it knows which Messages need to be updated, and since the "pmID" is an Integer, then as long as I sanitize things by casting to an Integer, and using Prepared Statements - which is actually the only way I know how to do database stuff - then I assume that I will be okay from a security standpoint?!

Yes. Just remember in your SQL where clause don't just do where pmid='<the PMs ID>' also do a members user id too so that they can only delete their own messages - eg:

delete from messages where pmID='$pmID' and userID='$userID'

That would mean that the user can only delete their own messages / mark as read etc. It'll be slightly different using prepared statements but that should give you an idea of what I'm saying.

Also, not sure if you do this but you're best off constructing one long SQL statement EG:

delete from messages where (pmID='52' or pmID='51' or pmID='50') and userId='$userID'

That will let you do the entire thing in one SQL query rather than 30 or 40 seperate queries. To make it (very basic - you'll need to do your own checks)..

I know you're concerned at the speed of development but I urge you to reconsider doing your updates in one SQL statement. Why?.. Personal experience.

When I first got into PHP / Mysql years ago I wrote the biggest and best code for my site.. but I couldn't figure out why certain pages were so frustratingly slow compared to others. I put it down to my computer (which was running the wamp setup) not being up to the job. Only when I turned on mysqls query log did I realise why it was so slow. Some pages had 200 queries running and it was grinding down the mysql server. I certainly learned a lot about sql optimization that week! That was for one user - me. Imagine that multiplied by a few thousand users and it will crash even the most powerful servers.

As for the suggestions, yes all of the suggestions put forward will allow you to do what you want. You'll need to make them fit in with your code so to speak.

After sleeping on things, it seems that we are all going about things the difficult way to my original problem. (Yet to be completely confirmed.)

How so?

Well, my end goal is that when the user clicks on the Top Check-box, and chooses an action and "Go", that *all* Messages get updated.

We have all been looking at how to pass an entire Array holding all of the Messages back to my script so it knows what to update.

But this morning, I came to this conclusion...

Why not just identify when the user checks the Top Check-box and submits the Form? If that condition is "TRUE" - which is very easy to identify - THEN I can run a SELECT query on my "Inbox", and use that results-set on my UPDATE query.

In other words, instead of running a SELECT query that identifies all of the Messages that need to be updated, and then trying to figure out how to pass that entire list back to the same script, why not take the easier path of just returning a simple Yes/No flag back to the script, [b]and then run the SELECT query?![b]

I know you're concerned at the speed of development but I urge you to reconsider doing your updates in one SQL statement. Why?.. Personal experience.

When I first got into PHP / Mysql years ago I wrote the biggest and best code for my site.. but I couldn't figure out why certain pages were so frustratingly slow compared to others. I put it down to my computer (which was running the wamp setup) not being up to the job. Only when I turned on mysqls query log did I realise why it was so slow. Some pages had 200 queries running and it was grinding down the mysql server. I certainly learned a lot about sql optimization that week! That was for one user - me. Imagine that multiplied by a few thousand users and it will crash even the most powerful servers.

Okay, Tango, based on my last post - and the need to "break" my code AGAIN to make it run better, I might as well at least take a peak into what you are suggesting?!

If I revert back to my original code which built my Inbox based on the results-set from my SELECT query - and not use an Array - then I have this code in my HTML section...

Sorry if you guys already told me how to do this, but how would I take all of the values in my msgArray - which comes from my Form - and convert it into a format so I could do just ONE UPDATE query, versus enumerating through each Array value, and running a separate UPDATE query?

Also, I am curious what everyone thinks about the change I mentioned in my last PM?

(In retrospect, it seems silly to run a query to populate my Inbox initially, them copy all of that data into an Array, then convert it to a format that can be passed in my $_POST array, and then convert it again, and then use it in my UPDATE query?! It would be much to just pass a "Checked"/"Not-Checked" value when the FOrm gets submitted...)

Actually I'm going to support this over my serialize suggestion as it would be easier and simpler to implode an array into a string for the form and then explode it into an array for processing.

The only slight risk is that someone could modify it before transmission whereas with a serialized array string it's not as easy to understand from the laymans POV.

So maybe the idea I came up with this morning is even better yet? (If I just pass whether the User checked the "selectAll" cehck-box, that is *much* more secure as far as protecting against hackers, right?

Also Deb, remember in your SQL to use "where user = '<users id>'" along with your where / id clause otherwise a malicious user could supply their own message IDs and wipe out another users inbox.

If your page displays ALL messages at once, rather than being paginated, then you could, as you suggest, just pass a yes/no value and execute a query against all the users messages in the database. But if they only check a selection of the messages then you still need to pass this information - that is, which messages were checked - to the other page, using the methods previously discussed.

If the messages are paginated then, assuming they check ALL, you would need the actioning page to be aware of which page they are currently on. That is, to be able to identify which page/group of messages need to be actioned. Or, again, pass the (full) list of current message-ids to the page.

But I'm not fully aware of your set up so the above information may not prove entirely relevant to your site.

"I'm here to save your life. But if I'm going to do that, I'll need total uninanonynymity." Me Myself & Irene.
Validate your HTML and CSS

Now please bear in mind I still don't use mysqli or prepared statements (Fou-Lu keeps dropping subtle hints my way but I've managed to get away with normal mysql for years ) so I'm unsure how you bind the parameters here using a dynamic query like this.

Now in theory, you could do this in your code but I gave it a try and had nothing but pass by reference errors thanks to php changing the parameters in call_user_func_array() - before php 5.3.0 it would pass it's parameters as references but now it passes as values instead which is a pain for mysqli_stmt_bind_param() which wants everything passed as references ruling out the above code. You could however use mysqli_query() though. I've spent over 2 hours chasing my tail on the reference thing so I've not had chance to test that but it should work in a similar way to mysql_query().

Edit: In theory to get around the pass by reference thing, you could probably run mysqli_stmt_bind_param() as a string with it's parameters through eval(). It's a very dirty hack but I did it once in some code somewhere in spectacular style.. worked perfectly. I just can't remember how, where or when

Fou-Lu, if you're out there I think this reference thing is up your street for solving.