redbullmarky

quite the opposite - a dedicated server will normally give you much more space, etc than a shared service. also - a dedicated server is a complete machine just for your site(s), whereas shared hosting will cram many sites all on the same machine - meaning you all share the server's power, and run the risk of a dodgy script within someone's space bringing down the lot. and as Chris said - a dedicated server will let you install what you want. Tired of backwards hosts that just give you PHP 4 and Mysql 3.23 ? Tired of hosts that won't turn off register_globals or install xyz package? no worries! install your own! overall with a dedicated server, you're paying for the performance, stability, flexibility, (security?), etc.

please familiarise yourself with the boards here before posting - the descriptions on the main page should be enough for you to pick the best place to post

lol there's nothing written anywhere that says you have to learn all of the PHP versions in order. Getting to grips with what's up and coming is what's gonna make people get excited about it and use it when it's finally released, rather than having this current situation where PHP 4 is still around and the most common even though PHP5 is far superior in many ways.

start with all the features you want now (more detailed than just 'Videos' - eg, what do you want a user to be able to do? can anyone view/download them? can they be commented on? etc etc) - as well as ones you may wish for in the future. once you've got a detailed idea of what you want, a sitemap will help. once all that's out the way, then you'll be more clear on things to move on to what tools are best for the job. I find it very hard to decide outright whether to use smarty or not, or whether to use Cake or CodeIgniter, etc until I at least have it clear in my head what the site should achieve.

http://www.phpfreaks.com/forums/index.php/topic,169910.msg750419.html#msg750419

your question is very vague and covers many areas. you'll need to give us a fair bit more detail to get any help.

based on my thinking i explained just above, can you explain further?

re number 3: in my thinking, my Page object I guess would represent a row data gateway to the page's DB record. The page's DB record holds the values that are embedded in my templates (eg Title, Author, Body, etc), as well as stuff like parent id, etc. so ideally my page class would read the relevent page data, render the template and return the actual output. thanks guys so far. Cheers Mark

Hi all Right, I seem to have hit a brick wall. The more I read different ideas of OOP, and the more I see it implemented, the more confusing things get - so in a nutshell, I'm trying to "forget" a little, and go back to basics in order to get a CMS I'm building off the ground properly. The biggest issue is keeping classes as independent as possible, but knowing what to set up, where, how, what to pass to constructor, etc. I'll use my current project as an example. I'm sure I'll need the following: - session class - database class - request class (for handling input variables, files, URL, IP's, etc) - template class (for rendering templates+tags) - a "page/object" class (for loading a page from the DB with its vars/settings to be inserted into the template - returns the final output, though i'm considering returning a "response" object that can handle other MIME types such as RSS, XML, images, etc) - a config class for handling site-wide configuration. Now - I want to keep things flexible and very simple. My questions: 1, my session class may or may not require the use of a DB, depending on whether I need to store sessions in the DB, or whether I wish to use PHP's built in session handling. 2, how should my config object be passed around/accessed? Singleton? Config::getInstance() ? via a registry? 3, my page object needs a simple constructor, ideally just taking either the request URL, or a request object - as i'll need to be able to "spoof" requests from time to time from other parts of my application. What would be the best way to set up the constructor here? It'll need all of the classes mentioned previously. as it stands at the moment, my constructor arguments are a mess, dependent classes are instantiated/accessed all over the place (sometimes passed, sometimes instantiated in the constructor or where needed, etc) and things look far from flexible - ie, classes look a little too dependent on eachother. if anyone has any advice on how the above classes might sit together nicely, whilst still giving me the flexibility long term, that would be great. Using PHP 5.1 Cheers! Mark

agreed with thorpe. PHP can do the trick nicely, unless you have a real need to use custom tag replacement. Take a read of the following article: http://www.massassi.com/php/articles/template_engines/ If seperation is your only/main goal, then that will allow you to use PHP but still provide seperation of your templates.

no. the freelance forum is read only. contact the person directly if you wish to make contact.

yeah i reckon that could work. though you could turn it more to your advantage and make sure that your social networking site DOES have a twist, rather than becoming YASNS * * i thought i was being clever, but it turned out someone already coined that one

personally i think it should be down to the person who invents these things. if MySQL say its "My S Q L", then that's good for me. if the powers that be name a particular technologyset the same as a particular brand of toilet cleaner, then fine. i'll use that too. wizzywig is kind of understandable, as it's far too long any other way. I was too young (if not born?) when that one was coined, so can't say whether it was or wasn't the "coiners" that decided on the short, common word.

me too. it does do my head in when people say "My Sequel" or whatever.

I might just be short of a few bits of education or might be being stupid, but surely the whole point of captcha is to determine whether the user is a bot or not, as opposed to just trying to irritate the user? If you have ways other than the captcha of finding out what sort of user they are, enough to fill in the captcha form for them, then surely you can just do away with the captcha altogether?

either or. using what he has there will get you a decent (albeit basic) understanding of using things like that - try and put a mini site using it, for example - and you'll be able to better judge if it fits your requirements. but as it's quite simple, using it to write your own shouldn't be too tricky. my own, for example, is based on that with the addition of GZIP support, caching, loading templates from a database, etc - all of which is still quite lightweight but easily changed for each project i do and the requirements.

as i put earlier. works fine on any server that supports php. Status codes like 404's are mainly useful for search engines, as they'll stop attempting to crawl the page in future. In terms of the original question - Azu, it's not possible.

please do NOT double post - i've deleted your other topic as a result. also - i'd recommend you give something a try, firstly, and post here any specific issues you're having with your code. this forum is not for us to supply you with code (especially not homework/coursework). there are tonnes of tutorials around (including those posted by farkewie) that you can follow that can get you going in a few hours, never mind a few weeks.

yep. if you're on PHP5, and you keep things fairly well organised with a consistent naming structure, you can make use of the __autoload magic function to wrap your includes in. this saves having to use includes all over the place.

have you tried it? function names are not case-sensitive, but the general rule of thumb is to write them as they've been set up. most (all?) built in functions are declared in lowercase, so it makes sense to keep it that way - it might make it clearer to read in some ways, but a) most syntax highlighters won't recognise it properly, hence making code harder to read and b) the confusion of seeing a function in a different case to the norm, coupled with not knowing if they're supposed to be case sensitive or not, might lead some coders who look at your work to think you're using a different function altogether - hence making it harder to understand. so yes - stick to how they're declared = less confusing for all.

the "page not found" you speak of is an apache (or other) server thing, not a PHP thing. die/exit both terminate the script at once. if you wish to replicate the not found page, you'll need to send a 404 header, which makes absolutely no difference to what is displayed but sends the correct header to the users browser/search engine bots, etc: <?php function die_404() { header("HTTP/1.1 404 Not Found"); echo '<h1>Page not Found</h1>'; die; } die_404(); ?>

i might be wrong, but try removing the commas (and your quotes?) in your $money = "90,000,000"; line - only actual digits and a decimal point/negative - are valid in a number when used in this context, else it's classed as a string. you can use money_format() or similar to display the number to the user "properly" on the page, but for the sake of comparisons, etc - a string wont work.

the ? ternary operator, and is pretty much an equivalent of if/else. so your code converted to the if/else way would be: <?php if (isset($HTTP_POST_VARS['mode'])) { $mode = $HTTP_POST_VARS['mode']; } else { $mode = ''; } ?> the bit before the ? is the condition. the next bit is the value to return if the condition is true, the last bit if the condition is false. on another note, i'd recommend using $_POST instead of $HTTP_POST_VARS due to the latter being deprecated. Hope that helps Cheers Mark

injecting stuff into SQL/pages, etc is only an issue if you're actually USING post/get data. so unsetting it completely as suggested by PHP_PhREEEk would not be of much use, as you wouldnt be able to use it. you should have an idea of what format you expect input to be, so just check the input and make sure it's as expected. take a look at preg_match(), mysql_real_escape_string(), etc as a couple of functions that can be useful in checking/filtering user input, in addition to your usual if/else, etc. the rule of thumb is don't trust ANYTHING from get/post/cookie. my rules of thumb: 1, check/filter input using if,'s, else's, preg_match's, etc - reject anything slightly dodgy. 2, use mysql_real_escape_string on items before putting them in database 3, use htmlspecialchars if outputputting user inputted data to the screen to prevent XSS - a good example being where you're repopulating a form with data user has entered. (like a contact/registration form with errors) there's a fair bit to it, and you could do worse than look into this type of things very carefully. security is not something that should be taken lightly or overlooked in the slightest. hope that helps.

imagecopyresized / imagecopyresampled should do the trick. http://uk2.php.net/imagecopyresized http://uk2.php.net/imagecopyresampled edit oops meant imagecopyresized, not imagecopy.