gizmola

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. ';

Wrong approach. What you should have is a row for each friend. Your structure supports this fine.

You're going down the wrong path-- xhtml is about using a prescribed set of tags in a standard way, not about naming your files .xml.

file_exists function provides this for you. $filename = '/path/to/foo.txt'; if (file_exists($filename)) { echo "The file $filename exists"; } else { echo "The file $filename does not exist"; } ?>

With mysql you can turn on the slow running query logging. There are a few ways to do this, but the one I'd suggest is adding this to your mysql configuration file, which is typically named my.cnf. It's often in the /etc directory or /etc/mysql directory, but that depends on your server config. Edit it to add this under the [mysqld] section # Logging set-variable=long_query_time=5 log-slow-queries=/var/log/mysql/slow-queries.log You might need to change the file path to suit your server config -- for example I assume here you already have a /var/log/mysql directory. You can also play with the long_query_time making it longer or shorter (it's in seconds). You have to restart mysql after you make these changes. Once that's working you should open up a shell and tail -f the file, then watch your server run through it's paces, and test things. You'll see the queries that are taking a long time. If you find queries that are tablescanning then you'll look to see whether there is a sensible index that you can add. Beyond that there are entire books on query optimization. It's too complicated a subject to dash off a simple reply.

Agreed. I did try and answer the original poster, but he seems to have gone dark -- even PM'd him. I'm about 99.9% sure it's a permissiosn problem.

Typical way of doing this is to store rows in a database table. Take one of those tutorials you mentioned, and get the code working, and ordering is trivial. When adding and ORDER BY clause to a sql statement the default is Ascending order. To reverse that and have it be Descending you simply tack on the DESC keyword to the ORDER BY. SELECT * FROM yourtable ORDER BY postdate DESC Voila, newest posts first.

With that said you can use reserved words as column names, but you have to enclose them like so: `primary`. Now to the bigger question --- your table structure has implemented the classic repeating group (primary, secondary, third) which I assume from the example is a foreign key to a Breed table. Really that should be a many to many. Tables should be dog_account, breed, dog_breed, where dog_breed is something like: (dog_id, breed_id, percent). Then you wouldn't have to construct ugly or queries like the one you're doing now.

The PHP manual says that move_uploaded_file() will issue a warning with some more info when the file can't be moved. I think you're on the right track in thinking it's a permissions problem, probably of the directory where you are trying to write it, although you didn't provide your code snippet, and you could have a problem with your destination file path. Are you running php as fastcgi or as mod_php? If mod_php then the user that needs the permissions to rw to the destination directory is the user that apache runs as.

No i wasnt suggesting an answer just another question on how I could use a variable to save the file. In answering you I completely blanked out on the fact you wanted to use a variable -- I amended the code example so it uses a variable. As I stated, No problem, you can do it.

Great to hear, and thanks for providing an update for future readers.