trq

The reason you haven't had any response is likely because you haven't asked a question. Telling a forum full of developers your goals is of little help. We are not interested. If you would like help, you need to ask specific questions and let us know exactly where you are stuck.

Your issue is as clear as mud.

http://php.net or https://bugs.php.net would likely be your best resources for question #1. As for question #2, there could be many reasons. Number one is probably simply that that is all there version of the OS currently supports. It can sometimes be a pain to update an OS just to get it's package manager to pull in a newer version of a particular piece of software but unfortunately, a lot of "server" distros are fairly slow moving. Having said that, there are numerous advantages to 5.3 and again with 5.4. If this servers primary task is serving up applications built with PHP, the pros should far outweigh the cons.

I am aware of what your trying to "prove". Unfortunately though, your opinion doesn't mean proof. Do you understand? You haven't provided "any" proof, just opinion. Opinion (and yours in particular) carries very little weight.

Your issues have nothing to do with what versions of php you are using. Your newer version obviously has error reporting set too low, so you are simply not seeing these errors. When you are developing you should have error reporting set so that you can see ALL errors.

Use a login system (with a "remember me" if necessary).

Neither of those links prove your point at all.

View source only ever shows wat was in the document when it was first requested, inspecting the elements gives you a much clearer picture of what the DOM looks like as it changes via scripting. You going to need to give us a clearer description of what the problem is exactly however as looking at your page and reading your thread, I'm still lost.

What have you tried? Where are you stuck? We need to see code.

That's not really what branches are for.

As requinix just said, use a shebang.

It is not "integrating with Symfony" so much as it is simply making use of some of Symfony's components. They are not alone in this regard. Even a lot of the modern frameworks are using Symfony components.

Depending on your "sub projects" you might want to look at composer. It's a dependency manager for php.

Looks like cron is trying to execute a php file using bash. You need to tell cron you are executing a php file.

A browser can only browse to files that it has access to.

BS.

Again. Not all design patterns require OOP. MVC for instance can be written quite easily in procedural code.

1.7.4 / 1.8.1 these are version numbers of what? It sure aint PHP.

tmux isn't a terminal emulator. It's a terminal multiplexer. xterm and the like are terminal emulators. If your using a terminal from a Linux desktop it is likely that you are using a terminal multiplexer (tmux) from within a terminal emulator (xterm etc etc).

mysql_insert_id.

For starters, the mysql extension has been deprecated in favour of mysqli or PDO. Both of which support prepared statements. If you really must use the mysql extension, take a look at mysql_real_escape_string at least.

Cool. That still doesn't help us at all. Are we done here?

Closing this topic. OP no longer deserves help on the subject.

Learning to read code is a skill in itself that needs to be learnt. In a lot of cases, just because you can write code does not mean you can read it well. What most people do is skim over the code too fast because they just want to figure out how a particular part works. They might skim the code beforehand. This can ofte trip you up. The first thing I always do is try and locate an (execution) entry point. Where does the execution of the piece of code I am looking at start? From there, you simply follow the logic (slowly) all the way into (and through) the part you need to understand. I'll usually do this a few times making sure I understand each block as I go. If I hit a point where I am lost, go back up a bit until you find your (execution) path. With practice, this process becomes quicker. Make sure though to always stop yourself from skimming past parts you think you understand until you truly do understand them. This process works for small blocks of code all the way up to larger more complex systems. Find an entry point and follow it. I thought I was reasonably good at this skill until I started working where I am currently. Our code base is currently over 2 million lines of code in several different languages spanned across two svn and several git repositories. Nothing is documented at all. I would read more code in an average day than I would write and it is VERY common for me to need to wonder into some part of our applications or libraries that I have never been before. There are guys at work that you can ask for help / advice, but there is no one there that knows the entire system well enough to get you through all situations. Hell, if we spent all day asking each other how different shit worked we would never get anything done anyway. Reading code is a very important skill to have. I actually think a lot of developers under estimate its importance. ANyway, to answer your question. No, your not likely to find some walk through that instructs you how some code base works. To read even the best documented code you still need the skills to be able to follow the execution path. You need practice, there are no short cuts.

And the results are?