gizmola

Ok, well, php has the nice wrapper function setCookie. The problem with cookies is that they go into the http header, so this must be set before any output is sent. Because session handling typically involves setting a cookie, sessions tend to have the same issues. In other words, you need to make sure that you do this in a way where no output has been returned prior to your function being called. The pseudocode to this, you write 2 functions: function adViews() returns count of views in last 24 hours. All this function need do is check for the value of the cookie. function adViews() { if (isset($_COOKIE['adViews']) && is_array($_COOKIE['adViews']) { $adView = $_COOKIE['adView']; foreach ($adView as $name => $value) { if ($name == 'viewcount') { return (int) $value; } } return 0; } else { return 0; } } In your ad code query, what I'd suggest is that you alter that query to include a "WHERE tag_id NOT IN (...)" clause when the results of the adViews() function is > 3. I don't know the schema of the tags table, so I'm guessing at how you identify this ad(s). So in essence, when the ad is this special ad, the query simply excludes it from the result set, no muss no fuss. Now you simply need to deal with the possibility that the person has seen the ad. This again, may be tricky, because it's a chicken and egg situation. Prior to even showing them the ad, you need to count it as being shown, if you understand my meaning here. If you already have sessions for everyone, you might be able to substitute a session variable, and use that to create the variable when you start up the session. What this function needs to do, is check for the cookie. If it exists increment its value, otherwise create it with setCookie. There's no way to "update" a cookie, so updating it involves setting it again with setCookie. function countViews() { $firstdate = time(); $viewcount = 0; if (isset($_COOKIE['adViews']) && is_array($_COOKIE['adViews']) { $adViews = $_COOKIE['adViews']; foreach ($adViews as $name => $value) { if ($name == 'viewcount') { $viewcount = (int) $value; } elseif ($name == 'firstdate') { $firstdate = $value; } } } // increment the count $viewcount++; // Set the cookie setCookie("addViews[firstdate]", "$firstdate", $firstdate + 86400, '/', '.yourdomain.com'); setCookie("addViews[viewcount]", "$viewcount", $firstdate + 86400, '/', '.yourdomain.com'); } I by no means tested any of this code, just typed it in off the top of my head, so don't be surprised if there are issues.

When you make a query and you need the data you have to fetch it. My preference is to use mysql_fetch_assoc()

Yeah things are pretty broken. It also might be a good idea to see what functions are being made available from the wsdl: $client = new SoapClient("http://refrigerantcompliance/RefrigerantComplianceService/Service1.wsdl", array("trace" => 1)); var_dump($client->__getFunctions());

This is not a simple endeavor. It's going to require a custom solution, and while I can suggest to you a hack that can probably developed and tested in an hour or so, the first question you might want to ask yourself is-- is it worth doing this for this one client? If the money amount is worth it, then -- sure. So you have 2 options --> cookie as p2grace suggested. Pros- will work nicely and limited overhead for your server. Cons-- debugging testing harder. Doesn't work for anyone who has cookies set off. Depending on the nature of your site, this may be acceptable. Serverside solution -> pros, impervious to clientside environment, doesn't require cookie debugging or intrusive installation of cookie code. Cons: tracking only by IP, some people share IP's hence they will artficially throttle views. I'd rather not go into the specifics of both, so it would be good if you expressed a preference for one solution or the other.

You need to do some debugging it looks like. My first guess is that the parameter for 'GetJobs' is not an array. Try adding in: $client = new SoapClient("http://refrigerantcompliance/RefrigerantComplianceService/Service1.wsdl", array("trace" => 1, "exceptions" => 0)); $result = $client->GetJobs(array('GetJobs')); //Error occurs on this line echo "\n"; echo "Request :\n".htmlspecialchars($client->__getLastRequest()) ."\n"; echo "Response:\n".htmlspecialchars($client->__getLastResponse())."\n"; echo ""; // Note that $array contains the result of the traversed object structure $array = $result->GetJobsResult->JobDAO; print "Service Description:Please Select One"; foreach($array as $k=>$v){ print "".($k+1).$v->RequestNo."".$v->Description.""; } print "";

Although I don't disagree with wildteen88 in terms of the basic consensus, I don't seem much of a problem with using short tags, if you can control the server environment. Sometimes these issues have a way of being pushed by the people who write projects used by the masses, when there is more people writing php for sites or businesses where there is no concern about control of the php.ini file, or being able to enable short tags. Up until version 5.3 the default was to have short tags set to on. I don't have a problem with short tags, especially when used in templates. For example, there's no doubt that template writers will prefer: = $pageheader ?> Rather than the tedium of

Glad to have helped, and great attitude. +1 for you -- being open to constructive criticism is important for any programmer. Even though I'm an old salt I always learn things from working with other programmers on projects. FWIW, there's what I consider to be some excellent examples of Design pattern driven OOP design in the Zend framework. Take a look at some other their classes and try and understand what they're doing. Learning from the example of others is usually very effective.

When you don't know what's happening, you have to inject something to help you debug it. If you have the option, XDebug can also be very helpful, in terms of the additional information it can provide to you when there are errors. I'd suggest you first try and debug this by setting the path you're trying to create to a variable and echoing it out. if ($_POST['createdir']){ $newdir = $_POST['name']; $dir = $_GET['dir']; $root = getcwd(); $path = "$root/dir/$dir/$newdir"; echo "Creating ... $path"; $create = mkdir("$root/dir/$dir/$newdir", 0700); } Some other notes: - mkdir returns true/false. Your code is better if you check the result and handle errors. - You should check to see if the directory already exists. If it does mkdir fails.

James, No offense intended here, but I don't see the value of what you are doing with classes. It's great you are trying to use them, but it seems you are simply substituting member variables in a class where you could otherwise use temporary variables. There's no value in your example, to using a class variable to store a result set. With that said I don't see an obvious problem with your query syntax. Nevertheless you should check the value of the result returned from mysql_query(). We don't know what your table definition is, but any issue there in naming of columns could cause an error. At very least you should: if ($this->runGetNewIID) { //Got a result, go ahead and fetch in a loop. } else { // check mysql_error() }

For Desktop -> Ubuntu. For Server OS -> RHEL/Centos. If you really want to geek out on your desktop: Gentoo.

I agree with CV here: if you are accepting a post, it's better to read from $_POST. $_REQUEST is a big slush bag of input, and just opens up more attack vectors, so why bother to make it easier for someone to mess around with your site. In fact it can be quite useful to log attempts that are not using your prescribed method, as being people who are probing your site for vulnerabilities. I also think that Register Globals was just a really bad idea from day 1. Allowing someone to artificially inject their own variables into an interpreted environment, especially where people had a propensity to use exec(), not to mention system() etc. is a disaster of unmitigated proportions. It goes hand in hand with globals. Sure, a top notch programmer can code defensively and avoid these pitfalls, but to me that's not the point of PHP. The point of PHP was to not have to worry about baggage, overhead and syntax, and get down to being productive and achieving your application goals. Ironically register globals was a feature thrown in exactly because they wanted to make it easier for newbs to be productive, but it's one place where I agree entirely that the feature is far more trouble than its worth.

Hello. Please use php /php tags bbcode tags around your code. Makes it a lot easier for people to read. [code=php:0] Your code [/[code=php:0] So to answer your question, based on your teacher's array: foreach ($products as $product) { $subtotals += subtotals($product['price'], $product['shipping'], $tax); echo "</pre> <li>{$product['item']}: {$product['price']}</li>";<br

That's what I get for not reading the OP carefully enough. Thanks Salathe... you are right, I missed that nuance entirely.

Did you look into rewrite conditions? You can specify that, for example you are on port 80 for the rule to go into effect. RewriteCond %{SERVER_PORT} 80

Lezlie, Wouldn't it be easier to simply get support from the programmers? Trying to restore from a backup could work, but it's kinda like taking a hammer to the side of your car, because there's a bug on there. Sure you will remove the bug, but you could also demolish half the car in the process. You could also introduce issues into the system, due to the changes you suspect were introduced by whatever sort of "upgrade" took place. I might also point out, that the "programmers" might not have changed things, but rather there could be vulnerabilities being exploited by a hacker. My advice is that it's important to have an expert look into this, especially when your business is at stake, rather than screwing around with something you don't really understand adequately.

If they've disabled this, then you won't allow you to run any of the commands that allow php to execute os programs, so there's no workaround. You are stuck using whatever internals, builtins and extensions that were included by your hosting company. Since we don't know what the script in question does, there's no way to advise you of an alternative approach to accomplish the same thing, although there might be one.

Just glancing at that code, I see a lot of very strange things, and code that is altering the structure of a table for some inexplicable reason. I don't see how it in any way relates to adding entries, although we don't know among other things: -what the application is -what the database structure looks like

Holly, 2 things to help you here. First, put bbcode around your code snippets. You can use php or code, but php is usually preferred. (Note that I modified your post for you and inserted these since this is your first post.) [code=php:0] //your php code [/code] The second tip is that you have to supply people with specifics. What *specifically* doesn't work at present?

Well there's 2 obvious problems with the query... First you can't have a comma before the FROM, and secondly you have an empty where clause, because your $add_sql variable is apparently empty when the query is executed. Fix those and you should be happy.

We can only suspect, because this isn't your real code, and you're quite probably omitting a key detail that would explain things better. A few things to know: The isset() language construct can be very confusing if you don't understand how it works. Admittedly the manual doesn't do the best job with it. This is probably more as a comment because it doesn't really explain what you're seeing, but doing what you're doing isn't the best idea, because the minute you do the $_SESSION['Xuser'] = assignment, unless you are doing an unset at some point, or you are assigning to null, isset is going to be true. That seems more a problem with your working code, since you will allow someone to get into the member system, even if $Xuser is an empty string. $foo = ""; if (isset($foo)) { echo "Foo isset"; } else { echo "Foo is not set"; } So what I'm guessing the real problem here is that what register globals is changing, is that it's hiding a flaw in your form handling code, where you are getting whatever $_POST or $_GET variables during the login. Perhaps you have a typo or some other small detail wrong, and register globals is hiding that mistake. It has nothing to do with how $_SESSION works or doesn't, as PFMaBiSmAd already explained. With that said -- register globals is really bad, opens up huge security holes and is deprecated. It doesn't do anything magic other than to convert all the variables that come in from the environment into global variables.

Again... you need to figure out which query it is that is failing, so it would be good to change your die() statements to die($sql . ' | ' . mysql_error()); In regards to your comment about time, I got the gist of that .. what I was saying, and still am, is that you can do date arithmetic in your queries directly, rather than using timestamps and subtracting seconds. I show how to do all sorts of things using the built-ins and DATE_ADD() for comparison purposes. Much cleaner, easier to understand, and takes advantage of mysql's features.

Well, it seems you need to determine from your input whether it starts with the 'MSG' first. So you would have to amend the code somewhat. There are several things you could do, that are variations on what has already been explained. Truthfully it's trivial and I'd like to see you writing some code and trying some things, rather than me writing out the code for you.

Whooopsie .. I left out the optional parameter in my example. Should have been: $msg = explode(',', $input, 2); I used trim to get rid of start and ending whitespace around the parsed elements. It is going to parse the string on the first comma it finds and split that into 2 pieces that it sticks in the array. If you want to retain the whitespace you can, by not trimming, although I don't think that's a great idea. Regardless, explode doesn't care if there's whitespace, and it will retain that ... it simply breaks the string up on the first comma it finds. Last but not least, if you have a question about what something does, it's a good idea to write a little test script and try it out.

Yes probably. Fastcgi is often used in shared hosting environments, so that they can utilize suexec support in apache. This basically allows them to run apache vhosts as your hosting user, rather than having everyone share the global apache user needed with mod_php. Since your user is probably quite limited as to programs you can see if you were in a shell, php is likewise limited as to what files it can see, exec, etc.