Spaghetti code and redundancy

Hey, I’m new, so please understand if I put this in the wrong section.

I did a lot of programing before learning web design, so I’m constantly thinking about reducing redundancy, and making sure it’s easy to change the location of something.

I’ve run into a problem designing my site. The nav bar is the same on every page, and if I just copy-paste it, making changes to the nav bar (adding new pages, etc.) won’t be very easy. I tried php include, but that requires me to pass the path to each different directory as an argument in a function, which still requires me to change every page if I move something that was linked to in the navbar.

For example:
In navbar.php

function navBar($pathToHome, $pathToDir1, $pathToDir2) {
   echo "<a href='".$pathToHome."'>Home</a>";
   echo "<a href='".$pathToDir1."'>Dir1</a>";
   echo "<a href='".$pathToDir2."'>Dir2</a>";
   echo "<a href='".$pathToDir2."/myFile.html'>My File</a>";

In /dir1/index.php

navBar("../", "/", "../dir2");

I’d like to be able to link to files relative to the site root, so in my included php file, I don’t need to put anything in a function. Like so:


echo "<a href=''>Home</a>";
echo "<a href='dir1'>Dir1</a>";
echo "<a href='dir2'>Dir2</a>";
echo "<a href='dir2/myFile.html'>My File</a>";



Changing the location of a file would be as easy as changing it in the navbar.php file.

Is there any way at all that you can think of to accomplish this? I just can’t see sites like facebook changing millions (billions?) of pages just because they moved a file.

Sorry if I haven’t been clear, feel free to ask for clarification, and thanks in advance.

Site root is “/”. Then add the full path.



One thing to consider: Users will make bookmarks to those files, and while re-structuring your site once every few years probably can’t be avoided if you’re a successful start-up, you should make sure that at least your main directories doesn’t change their names. Also, using upper-case letters should be avoided in URLs.

In addition to Gary’s advise, here’s a couple of tips:

  1. If the included file will only contain HTML, you should not make it a PHP function, unless there’s a security reason why the file shouldn’t work as a stand-alone file. Keeping the file as PHP will increase processing time, as PHP will have to process all the commands.
  2. Menus are usually marked up as an unordered list.

In other words, this would ideally be your navbar.php (or .html):

<ul id="menu">
 <li><a href="/">Home</a></li>
 <li><a href="/dir1">Dir1</a></li>
 <li><a href="/dir2">Dir2</a></li>
 <li><a href="/dir2/myfile.html">Dir3</a></li>

Wow… I was kinda thinking it would be more complicated than that… thanks gary.

Thanks for the tips, erm… “C”. My navbar is already an unordered list (the code I provided was created purely for clarification), but I forgot that making a fuction puts more of a load on the server.

I usually use “.inc” as the suffix. For example, The server and the client don’t care, and it is easier to see the file name and know what it is.

You need not use the .php suffix on the included file, since the ‘mother file’ tells the server how to deal with it. The included file is not treated as a separate entity; it is at heart a simple copy/paste job.

The same parameters apply if you’re using Server Side Includes (SSI), an integral server function.



the simple solution was already mentioned, but it I need to say there is also another easy PHP trick for this.

$_server[‘PHP_SELF’] would give you the url of your current document, removing all characters after the last"/" gives you the current directory of the file so you can move up and down your directory structure using that as a guide point.

Ultimately, you cant create a good program,m if you haven just simply created a good structure… if you expect to be creating folders willy-nillyandnot using some sort of tracking … there will be no pattern to create good code from.

What d_p suggested using $_server is my preferred method, because quite often I can’t guarantee server root (much less local root during testing) is going to be the root of my program.

Though I also tend to keep all user page requests to that root directory – to me wasting an entire subdirectory on individual pages or even grouping pages – ESPECIALLY when you can leverage PHP to load the sub-sections seems a bad idea…

Especially when you can force all page requests to a single index.php – then have index.php figure out what to show for content.

One big tip – if you use single quotes instead of doubles, you wouldn’t have to open and close echo like crazy and you could have nice neat formatted output.

echo '
 <ul id="menu">
  <li><a href="/">Home</a></li>
  <li><a href="/dir1">Dir1</a></li>
  <li><a href="/dir2">Dir2</a></li>
  <li><a href="/dir2/myfile.html">Dir3</a></li>

Then you only have to escape single quotes, which should occur a lot less frequently. Double quotes take longer to parse, longer to execute, result in more function calls, and in general should be reserved for the handful of cases where they make sense… Which is to say 1% of the time.

NEVER understood why so many PHP devs make their lives so much harder by using double quotes on everything – is there some common book or resource teaching this bad behavior or something?

Thanks for the tip.

I think it’s just because double quotes are natural to everyone who learned to write english (or another language using double quotes) before they learned to write php.

Hmm… maybe my learning pascal/modula thirty years ago skewed my view? (those only let you use single quotes for strings)

I’m guessing it’s because a lot of PHP developers originally started writing HTML, where double-quotes are standard.

Careful of the security considerations here - if someone accessed the URL directly, and it contains important config information (eg database user/pass), anyone will be able to read it easily. If it ends in php, the config settings will be parsed and hidden.

I’m amazed people USE echo as much as they do. The only time it appears in any of my applications is in the template class:

echo $this->returnOutput();

As for the original question - I NEVER assume that the site is going to live in the document root of the server (for one, I develop everything locally in a subfolder - eg http://dev/projectname/httpdocs/). Imagine if, say, PHPBB did that, and how many of their users put the application in /forum/. It would all break!

I use

<base href="http://dev/projectname/httpdocs/">

and relative URLs for all my links - ie, make sure they don’t start with /.

The value of the base href attribute is set from a config file in my application framework.

Why wouldn’t you simply disallow viewing *.inc files? I.e.

<Files ~ "\\.(inc) $">
  Order allow,deny
  Deny from all

A similar rule prevents viewing .htaccess and .htpasswd files

<Files ~ "^\\.ht">
  Order allow,deny
  Deny from all

Besides, that info belongs in a directory accessible only to the mid-tier logic, one not in the server root tree.



Indeed, but if, with a separate exploit, someone was able to upload a replacement .htaccess (entirely possible with some file upload bugs), you are stuffed. Keeping outside the document root is much better, but you do see people who don’t do that, or some shared hosting packages which don’t allow you to do that, all sorts.

Having said all that, my config files are actually .xml files, but kept outside the document root obviously.

I think it’s just because double quotes are natural to everyone who learned to write english (or another language using double quotes) before they learned to write php.

This would be bad reasoning. PHP is not human language…

there is only one good reason for the double quotes, and that is to be able to include variable output.

echo "<p>hello my name is $name. I will be your $server";

and this is just if it bugs you to see it coded this way:

echo "<p>hello my name is ",$name," I will be your", $server;

That’s another issue entirely. If someone were able to upload to your site, all files in the doc root tree are vulnerable. If they can access that much, your entire /~* tree may be at risk.

Keeping outside the document root is much better, but you do see people who don’t do that, …
If they won’t do one trivial security measure, you expect them to do another?

… or some shared hosting packages which don’t allow you to do that, all sorts.
Why would you rent a house without doors?

I am not arguing that you’re wrong, only that include files need only basic security; after all, they’re going to be pasted into your document for the world to see. You bring up password and configuration files, which are different beasts from include files. They do need a higher level of security, and they need to be invisible to the http server. Intrusion hacks are a completely different issue and need a different solution.



Indeed, but if they can overwrite your .htaccess and look inside the right php include/config file, your database is also gone!

At which point no reason to use double quotes – since they’re also SLOWER.

But then, I’ve always hated printf/double quote parsing/etc… It always seemed too… sloppy.