gizmola

No it's not. There is no security, and a lot of processing power required. I say again --- you have not secured anything just because you generate a hash and pass that because there is no secret involved, since the url param has the hash value IN THE URL! Where people make the argument for that technique is when they are trying to prevent people from randomly guessing id numbers, say for example in a system where you might have something like: showprofile.php?userid=4 And this lets a user see their profile. So naturally someone thinks --- let me try showprofile.php?userid=5 and they get the profile page of someone else. Regardless of whether or not they hash the userid in some way, that's still not security, if the requirement is that nobody should be able to see and edit a profile page other than their own. The solution to that problem is not to user url params at all and use session vars instead, and have the script pull the appropriate information from the database for the logged in user. Since that resides serverside, there's no need to even have url params.

Susan, First off, I glanced at html_checkout_process. This entire file does absolutely nothing other than interpolate a big string. While this has nothing to do with your question, there's just a much better way to do what you're doing there, and it's called a HEREDOC. Heredocs will interpolate values the same way as using " stuff $var stuff". You do this: $myvar = Put my html in here, and mix in vars like $var as I like. no need for escaping. Here's more stuff! Isn't this better! HERE; $echo $myvar; Secondarily, this is just oscommerce code --- so you should be posting in the 3rd party scripts section, as this isn't code you wrote is it? All things considered, I think the most likely explanation is that you have a configuration issue with your server, or paypal or both. There's no point in us trying to debug code that is part of a well known ecommerce system. Needless to say there's a huge difference in just indicating COD where there's nothing that needs to happen, vs. paypal where the paypal servers are being called and results are being stored.

I'm not sure what it is that you're trying to accomplish by calling md5() all over the place. You are accomplishing absolutely nothing at the expense of a huge number of hash calls. All that you could possibly hope to accomplish is to obscure the fact that you are passing a url param with the same name as the menu item? It's not like I can't take the md5 hash and just use that if I want to try and exploit your controller code. It doesn't matter if I don't know what it hashes to -- the hash is in the link and you're accepting it. This approach provides no security whatsoever.

Look at the array functions. There are a variety of ways you can combine two arrays together, and of course you could probably write the code to do this manually i'm betting. Once you have one array, your single foreach will work.

you can check prior to the loop, by comparing $this->metadata to NULL, for example: if ($this->metadata != null) { //Do your foreach //etc You can also turn down the errorlevel so that it doesn't include warnings, if there's no particular logic concern. Of course on a production server you should not have error reporting on anyways, as you will want to log errors instead.

I agree with everything Andy wrote, and I can add to it: Do you really understand your tables? This is how I approach most queries: 1. Write the query using a literal example and run it in phpMyAdmin. Does the query return the right columns? 2. Replace the literal portion with a variable as needed. You should test some semblence of this: SELECT paypal_payment_info.datecreation, paypal_cart_info.itemname, paypal_cart_info.itemnumber, paypal_cart_info.quantity FROM paypal_payment_info INNER JOIN paypal_cart_info ON paypal_payment_info.txnid = paypal_cart_info.txnid WHERE paypal_payment_info.datecreation = 'some date that matches format of datecreation'; Since we don't know what the datatypes are we're just guessing, but one thing you can't do is mix in a php function in the middle of a string and have it interpolate. You need to get the value first, assign it to a variable and then include it. Also, you have lots of spurious parens that aren't doing anything. Only add parens when you're sure you need them. After your first query runs, assuming you have a result set, you then need to fetch the rows in a loop, and inside of this loop you will do your UPDATE query. Again, there are just sooo many examples of this, you should be able to come up with something that resembles a working solution given a little reading.

Andy my friend -- just responding to the portion of this question that referred to "chron" -- Hopefully you guys will get the logic sorted, but obviously a loop is needed at very least A job that runs on the server is ideal, but it appeared to me from a quick google that Yahoo merchant doesn't offer this option. Although it's far from ideal, you can get around this by putting the script in webspace, and having another server with a scheduler run it for you. Yahoo serving looks pretty crappy if they don't even offer you a way of scheduling a job. There are of course other ways to hack something up, but it seems like we'd be getting to a point where we're no longer teaching someone how to fish, but handing them a bucket of fish instead.

What they were saying is that on a Unix system there is a generic scheduling daemon called Cron. If your server is unix or linux, then cron is available to you. If your update script works and can be called via the command line PHP, then you should be able to schedule it to run using Cron by making a cron entry using the crontab program. Crontab entries specify the schedule, and follow a format that is documented in the man page, and in many places on the internet, easily found with google. For example, su to root and use: crontab -e You should be popped into vi where you'll see the existing crontab. What cron needs in the crontab entry is the the name of the program to run, so you'll have something like: 29 * * * * * /usr/bin/php -f /path/to/yourscript.php > /dev/null The '*' indicates that for that element of time (minute, hour, day of month, month of year, day of week) to match all possibilities. A literal number matches only that time. So in the example above I'm specifying to "run this program on the Half hour, once every hour of every day." Hopefully this is enough to get you going, and have your scheduled inventory job running.

Umm, why would you want to do that? Often this is used by spammers to trick unwitting victims who think they are registering for something free, into doing the dirty work for spammers. I wrote about this phenomenon on my blog back in Jan 07: http://www.gizmola.com/blog/archives/73-CAPTCHA-busting-A-sucker-born-every-minute.html I think we need more specifics about the site in question, and the reason for doing a redirection to their registration system.

Looks good. Currently there's not really a reason not to have your check_login be declared static, because you are really just using it statically. As for the basic concepts you've used quite a few, with the abstract class etc. It's simple enough but what you've done is clean and concise.

Why not just use the Zend Framework. The examples and docs there are good enough to get going, and there's a relatively complete implementation that includes all the MVC components.

Insert or Update? If what you're going to do is use the selections to insert rows in some table, then with insert statements you can do: INSERT INTO myTable (id, someval) VALUES (3, 5),(3, 6),(3, 9) Hopefully you get the idea. These inserts willl all occur in one transaction so it's very efficient.

You'd probably need to provide the details of your database. People aren't mind readers.

It's pretty simple really. Do you have a project to work on? What is it that you want to do? The computer language is a means to an end. You need a project, no matter how simple, to work on. You will only really learn what you can do by trying to do it. Along the way you will make mistakes, and hit walls, and take wrong turns, but you will find out along the way what you are capable of, and you will become better and more knowledgable every hour and day you work at it. Like most things in life, it's a journey that begins with a first step. It sounds like the problem is that you haven't taken the first step, possibly because you are afraid of failing. While I can empathize, you have to realize that you are the one holding yourself back, and the fear of failure and hitting up against your personal limitations has become a self fulfilling prophecy. Sit down right now, and write down on a piece of paper a brief description of what type of system you are going to create. Then get started on figuring out step one. Don't worry about the big picture -- get one small piece working first, and this will start to snowball.

No, you can put them into the config file directly or into a a vhost section. For a lot of people, that's not an option as they are working in a hosted environment where modifying those files is impossible. With that said, if you have your own server, it's the best solution performance wise. FOSS projects offer the .htaccess approach because those sorts of rewrites are typically an option that can be turned on or off depending on the support for it. Not everyone uses apache. I should also add that mod_rewrite is not the only approach and you can get much of the same effect by manipulating the uri inside your PHP script. Those variables are available in the web environment in the $_SERVER superglob, and that code will work with most any PHP install regardless of the webserver.

These are fair questions, and hard to answer when you aren't yet bought into the concept of functions. If you consider PHP for a moment, it should be somewhat self evident that PHP is largely comprised of functions that your scripts call to do different things. But you've found that you can create different scripts to do different things, and link them together, and don't need to actually write functions of your own. Did you consider this example however? In your registration script, there is probably a point where you accept the user's password and store it somewhere. Most systems then have a login form that accepts that password and compares it with the one in the database to see if the user should be logged in. That could be a small block of code to perform the lookup, retrieval and comparison. Now consider, that most systems also have a profile page where users can set a new password, which usually (best practices) has a box where the user has to type their old password in order to update the new one. Why do this? Well the main idea is that this protects someone from stepping away for a moment, and having someone sit down and quickly change their password while they're away from the desk. So in that example you have a whole block of code needed to do exactly the same stuff, but now in two totally different contexts: login and change password. You could certainly cut and paste all the code into both scripts, and it would certainly work fine --- until the day you find that you made a mistake in the code and need to update. Now instead of having a function that is called in both places, instead you have to make the same changes twice, and retest twice. Hopefully this gives you an idea of why functions are extremely useful. Once you buy into that, you may be able to begin to buy into the idea of objects, which are really bundles of variables along with the functions created to act upon and manipulate that data.

The purpose of the tableprefix looks to be allowing for mutliple versions of the tables in question to be able to coexist, via the "tableprefix" variable. This has to have been saved somewhere and is probably brought in via a config or ini file. So when the db was created, rather than have an "invoices" table in the database, the table is actually names 'myinvoices' (assuming that the value returned by the getTablePrefix() method was "my". All that's happening is basic concatention of a string to create the SQL statement that is ultimately being executed. The $where variable seems to be a global, or it must not be working, so I'd agree if that's true that the design of this isn't the best, as relying on globals is a pretty poor practice. However, this observation is based on your snippet, and if you omitted things it might not be relevant.

Stated even more simply, in your example you implied that the promote() method would act upon or send a message to a user. What $a was meant to be was unclear, but we could assume it might be a name, or array of information. The result of course was a "user" object. In your static example, you called promote, but on what? Well what happens is that an object is created, but immediately disposed of. You could think of it as: a) I create user "Bob". Then I promote() "Bob". whereas your static example is: b) PHP created an object and executed the static promote() method. So hopefully you can see that the two things you were comparing weren't the same. If your example had been: myclass::promote($a) vs. $user->promote($a) then it would be a more interesting question.

We can't read your mind. You have to ask a specific question.

So first off, disregard MasterACE14's reply, it's sorry to say just plain wrong. Mgallforever's answer was correct, so if that's returning too many results it's because you have some problem with your code. What it boils down to is use of mysql LIKE, which allows you to do wildcard searches against strings --- simple stuff. Now here's the bad news. Your design has implemented in your "starring" column, what in essence is known as a repeating group. It may be beyond your current abilities to remedy this design flaw, but what you should have, is a seperate "star" table with one row for each star, and then a table between your movie (or whatever) table and star with *one row for each star* that is in that movie. You might ask why all that complexity is important. Entire books have been written on the subject so I won't try and do more than to suggest you read up on database design and normalization. In layman's terms however, not only would you not have to use a LIKE, but you also would have a design that would not degrade in performance the way yours will as your database gets large. Unfortunately, when using a %LIKE% query as the one you need to find a name anywhere inside the list of names, mysql can no longer utilize an index. So your query will result each and every time in a "table scan" where mysql will have to read the entire table from top to bottom -- and look in every row, scanning through it to find if the substring you are looking for is inside the list of names in the starring column. This may not be anything of consequence to you, as your database may not be very large, or your site may never have enough users to make this a viable concern to you, even though your design isn't relationally correct.

Or not. No your site cannot read another site's cookie. If it could, cookies would be useless, as they were designed to allow a browser to pass information back and forth between sites. If you look at how they work, cookie data is sent by the browser to the appropriate website on every single HTTP request. Cookies are "scoped" as it were, by the server domain -- easy enough to verify by looking at the cookies themselves, which you will see in firefox for example as being listed by the domain for which they were instantiated. Despite several descriptions, I'm afraid I still don't understand what you're trying to do precisely, or why, so I'm hard pressed to offer any further assistance, other than to tell you, that you're going down a path that at best will end in failure, and at worst borders on a cross site scripting attack against the original site.

What you have currently is a very common pattern, referred to as a fusebox, junction box, front controller etc. There's nothing wrong with it. It seems you have 2 questions: 1. How to have different header content. Add a case statement at the top of index.php that emits whatever you want in the html HEAD section based on the same "page" parameter that's being used to include the section in the middle. 2. How to have "search friendly urls" There are a variety of ways to do this, but the most common one with apache is to utilize the abilities of mod_rewrite to convert your urls from what they actually are, to something that looks hardwired. Your goal then would be to: a) make sure that all requests get routed to your index.php b) break up the url into pieces and rewrite it so that the first directory after the url gets converted to the page= parameter This would allow you to then have url's that look like this: http://website.com/software There's many examples of how to do this, and lots of FOSS software like Joomla, Serendipity, Wordpress etc etc etc that have examples of how to write the needed mod_rewrite rules. Often they are stuck into .htaccess files.

Define simple. What wiki's and most CMS do isn't simple, for example a wiki does translation of wiki markup to html. Let's assume you're not going to have any of that, and will allow raw unexpergated html. In short, these systems store the content of the pages inside a database, and then render the output and translate it into html. Allowing editing of that could be as simple as displaying it inside an html form textarea. You simply pull the row that is stored in the db, and output it to the textarea. The only thing remotely tricky is remembering to escape and unescape the content. With mysql you would use mysql_real_escape_string.

Add the path to the fopen() function when you specify the file, rather than just the filename. fopen('/some/path/yourfile.txt', ....)

This is a big reason why people use PHP -- because anything you print or echo is returned to the client as html. So all you need to do is echo out what you want. echo 'Thanks for your submission. ';