.josh

Okay, in general based solely on what you've posted, you should have an array that looks like this: $products = array( 'price' => array(200,300,100,200,60), 'quantity' => array(2,1,10,55,1) ); Then you could for example do echo array_sum($products['price']); for the total price. However.. I have a sneaking suspicion you could probably be doing this more efficiently based on where you are getting the data from in the first place. For example, if you are getting the data from a flatfile or db you're likely already using some kind of loop already.. why not just throw a $total_price+=$price; in there to get the total? Or e.g. if you have some kind of array (e.g. session var) of stuff a user put into their shopping cart, why are you making a separate array structure just to get the total? Work with what you have (e.g. loop through what you already have for a total). IOW it seems to me that you likely already have the data in xyz format so it's not clear to me why you are trying to restructure things to get a total instead of just using what you already have. sidenote: I know you meant "index column" as in a separate column to act like a unique identifier, but fyi php arrays always have an index for each element. It will either be associative or numeric (or both). So in the example above, it's really the equivalent of $products = array( 'price' => array( 0 => 200, 1 => 300, 2 => 100, 3 => 200, 4 => 60 ), 'quantity' => array( 0 => 2, 1 => 1, 2 => 10, 3 => 55, 4 => 1 ) ); Just mentioning this because you can use that instead of a separate index column if need be, for example: $products = array( 'price' => array( 'prod_id_1' => 200, 'prod_id_2' => 300, 'prod_id_3' => 100, 'prod_id_4' => 200, 'prod_id_5' => 60 ), 'quantity' => array( 'prod_id_1' => 2, 'prod_id_2' => 1, 'prod_id_3' => 10, 'prod_id_4' => 55, 'prod_id_5' => 1 ) );

you need to remove the $ in front of $input_class

umm, checking if it's empty in no way makes it safe.

it is a trivial thing to change the value of an input field, regardless of what type it is. You need to make sure that $liked[1] contains an expected value, same as any other value coming from a request.

Name one thing vim can do that other editors can't do, other than excel at grabbing people by their nostalgic balls.

Although as an alternative hacky solution, you could do a mod rewrite rule to redirect to search.php if your query param is present. Example w/ Apache in .htaccess file: RewriteEngine on RewriteCond %{REQUEST_URI} !^/?search.php RewriteCond %{QUERY_STRING} (^|&)search= RewriteRule ^.*$ /search.php [R]

sounds like you need to look into restructuring your site to follow the MVC pattern.

We used to have competitions here but there wasn't much interest since our prizes more or less sucked. We have been talking about bringing them back with more substantial prizes though. Can't really share details beyond that at this time.

If $LRH_departure is showing rounded number then you must be rounding the number other vars before you do the calculation. Simple exercise: <?php $LRH_bankfull= 435.5; $LRH_current= 428.13; $LRH_departure = $LRH_bankfull-$LRH_current; echo $LRH_departure; // output: 7.37 php doesn't (necessarily) round by itself (until you get into much larger numbers after the decimal point), so you definitely have something that's rounding your numbers at some point.

you mean like Google Analytics?

give me your card number and pin so I can test it

If this "TAFE" thing expects you to use mysql_xxx functions then they are outdated and I have to wonder if it's worth being assessed by them... In any case, you didn't respond to the part where requinix pointed you at mysql_error

the regex calls you have in the code you posted could be improved upon, but at face value, I don't see anything wrong with them that would cause what you are seeing, so the error and those "//i" outputs (not sure that those are necessarily even the same issue) must be in a different file that what you posted.

If you really have no intention of storing it in a database or flatfile, and really are just going to send an email and forget about it, then you don't really need to filter or otherwise scrub the input for malicious code. However, unless you want the spambots to start using your form as a proxy to send out spam, I highly recommend you scrub the input of spammy type content.

To be clear, around here "help" means "I'm doing this myself and I got stuck on this specific thing so please help me understand what I'm doing wrong". It does NOT mean "I need this and I don't know how to do it so can someone please do it for me." If you want the latter, I suggest you offer more than "respect". On a sidenote.. Have you actually tried to sit down to translate it? I'm earnestly asking. My python skills are noob at best as well, but looking at that script..I'm pretty confident I could translate that to php easy enough.

Are you saying you do not have a development environment to test your code changes before pushing live? Do you really think it's a good idea to push untested changes live, especially when money stuff is involved?? Pushing untested code into production should NOT be an option, period. Especially when there is a user's personal info and/or money involved. But in any case, you call like this: $this->method1();

$row is an array of all the columns for the current row iteration. So you are attempting to use strlen and substr on the entire array. I *assume* given your echo, that you really want this: $row['col_5'] = (strlen($row['col_5']) > 13) ? substr($row['col_5'],0,10).'...' : $row['col_5']; // ADDED THIS LINE

If you are writing or altering your own code and are stuck somewhere specific, then ask a specific question. Otherwise, post in the freelance forum if you are looking to have someone do the work for you and are willing to compensate them. p.s. - I removed your link and file structure dump from your OP because without an actual question, it is just spammy at best, but also potential security risk.

They are called modifiers. By default, + is a greedy quantifier, meaning it will match everything it can possibly match, and then only give up what it consumes to satisfy the rest of the pattern. So let's say you have this string: And you have this pattern: #\[%(.+)%\]# So what happens is first the [%] in front of "quick" is matched. Then (.+) is going to match all the way to the end of the string. Then for the engine to match the closing %], the + starts backtracking from the end of the sting, giving up characters until it reaches the first %] it finds. So, instead of matching for 3 of those [%word%] things, you end up with one match looking like this: [%quick%] brown fox jumps [%over%] the lazy dog [%lorem%] That is where the U modifier comes in. The U modifier inverses quantifiers. It makes greedy quantifiers to be non-greedy. What that means is instead of matching everything it can and then backtracking, it moves forward one char at a time until the rest of the pattern is matched. So this achieves the desired match you want: that is, to only match until the next %] instead of the very last occurrence. So what you had wasn't wrong, per se. But there is another way to make quantifiers lazy: by putting a ? after them. This is what most people recognize, and what virtually every regex engine recognizes. Whereas most people barely even know regex, let alone the U modifier, and that modifier isn't available in a lot of other languages, which would make it harder for you to translate your regex to another language if it comes up. IOW using the U modifier is akin to speaking in double negatives.. you're technically right, but you're more often than not just going to confuse people. The i modifier is to make the regex case-insensitive. This isn't necessary in your pattern because you don't have any letters in it. The s modifier makes the dot (.) also match newline characters (by default, it does not). Again, unless you plan on having newline characters in between your [%..%] tags, this isn't necessary. If you have php5.3+ then you can do it like this: $ret = 'the [%quick%] brown fox jumps [%over%] the lazy dog [%lorem%] ipsum dolor sit amet'; $test='foobar'; $ret = preg_replace_callback( '#\[%(.+?)%\]#', function($m) use ($test) { return strtoupper($m[1].$test); // upper case the captured word }, $ret); echo $ret; If you are NOT on php version 5.3+, then upgrade! Seriously.. but if that's not an option at this time, then it's not (directly) possible. The workaround is to declare the variable as globally scoped. In general, this is a bad idea, as it defeats the purpose of functions having scope. But this is one of the grudgingly acceptable use cases for global variables, since there isn't really an alternative for older versions of php (seriously, at least upgrade to php 5.3). Here is how it would look: function makeUppercase($m) { global $test; return strtoupper($m[1].$test); } $ret = 'the [%quick%] brown fox jumps [%over%] the lazy dog [%lorem%] ipsum dolor sit amet'; $test='foobar'; $ret = preg_replace_callback('#\[%(.+?)%\]#', 'makeUppercase', $ret); echo $ret;

Also, and this is just a suggestion.. you should change (.+) to (.+?) and remove the U modifier, since a) the pattern's intention is more readily clear, b) the regex is more portable to other languages.

sounds like you added code to add another parameter to the url but didn't add any code to actually do anything with it. Alternatively, perhaps you did do something with it but perhaps you have a mod_rewrite in your .htaccess file that doesn't account for it?

You have been shown with numerous examples and tl;dr's breaking down exactly what is really happening in that condition. So at this point, either a) you still don't understand, and I don't know how better to explain it to you, or b) you do understand, and for some reason that is unclear to me, that is in fact the intended behavior you want out of your script. In either case, I guess I have nothing more to say.

I agree that it would be helpful if it were mentioned in the profile area. But there aren't any settings in the admin interface to make it show a message on your profile page for that. Perhaps you could make a feature request on the IPB forums or make a mod! In any case, we do mention it in the stickied README in this forum.. because as we know, everybody reads stickies...

a) It means your mysql_query failed, so it's returning false instead of a result resource. b) The mysql functions are deprecated. You should update your code to use mysqli or PDO functions.

Your immediate issue is that your setter isn't actually setting the property. But also, generally most people either don't return anything from the setter, or else the return $this, so which allows for method chaining. public function setmyvar($varstring){ $this->myvartest = $varstring; return $this; } But as-is, this doesn't do much and there's no real benefit of this over just setting it directly. Ideally you should do some validation to ensure that $varstring contains an expected value, or else throw an exception. But on the sidenote of return $this; : For example this would allow you to do this: echo $myobjA->setmyvar($varstring)->getmyvar(); Another note: I know you are *probably* just doing it for testing purposes but normally you wouldn't echo stuff out in your getter like that. getter/setter methods shouldn't echo things out; you should have other methods that handle presentation.