Most programmers have found themselves caught in this predicament at least once, the dreadful "spaghetti mess" code.
You've lost track of logical code flow in the application and you're doubtful that inputs & outputs will be predictable and accurate.

Adding additional functionality to the application becomes increasingly difficult and with each code iteration new bugs are introduced, maintenance is also becoming an absolute nightmare (especially for developers new to the project).

The reality is, there is no quick solution, and you'll most likely find it impossible to untangle the code and the only long-term solution will be to rebuild the application.

 

If you fail to plan, you plan to fail

Don't repeat the same mistakes:

  1. System Architecture
  2. Configuration
  3. Conventions & less magic
  4. OO programming is your friend
  5. Globals are your enemy

System Architecture:
I would almost always suggest MVC and a popular MVC framework like Zend Framework or Symfony, because these frameworks already solves the architectural problem.

If you really don't want to use a framework then I would suggest the following:
Read up on Systems architecture and specifically Design patterns

Configuration:
Configuration values must load at system startup, it doesn't matter if your configuration values are in a file or database, most importantly, values contained in the configuration storage must be unique to avoid the duplication problem.

Conventions & less magic:
Name your classes, variables, etc. based on the module that it's directly related to as well as it's functions i.e. Class Orders, Method Orders::Invoice().

A function or method should never work on global values, but should only be responsible for doing 1 task and return a value, or void(). If you call $Orders->createInvoice(); then you would expect it to do only that, NOT to also email the invoice in the background (which you won't be aware of).
If you want to email the invoice you should have to call it explicitly, $Orders->createInvoice()->sendInvoice();

If you are extending the Orders class into something else, then be sure to name it appropriately, i.e. class Orders_YellowBranch extends Orders, this way you'll know that on line 5023 of your code this class works only on the YellowBranch orders - no confusion.

Why less magic? Let your code be obvious, as soon as classes etc. gets too magical it become a nightmare to trace and debug, again the function or method must do what its name suggest $Orders->createAndSendMailAndDeleteRecord(), and that's all it should be doing!

OO (Object Orientated) programming is your friend:
Its quite amazing that there are still advocates for non-OO programming today, people who believe they can build rock solid systems using only procedural practices and static functions.

If you are writing a simple 1 page script then perhaps yes, but this is hardly ever a real-world scenario.
When using objects (classes) correctly they give us an automatic namespace which helps with the code logic and human readability as well, they can also be extended where the child class can inherit all members from the parent class and define additional members/methods i.e. Car class inherits from Vehicle class and can define additional methods like, sunroof, colour, or override engine to v8.

Globals are your enemy:
I guess most programmers today will already be familiar with the Globals problem.

For example, your application includes about 6 scripts in order to render the final Orders total page, each of these included scripts in turn also defines some global variables and also works on previously defined global variables.
Now in your main script you are calculating the Product total plus (+) Shipping amount and cannot get the right Total amount, perhaps script 2 is altering this variable, or is it script 5 unsetting this variable?

It becomes a nightmare trying to trace the flow of events and where exactly things are going wrong.
In PHP there is also a global array called $_REQUEST, this array will contain $_POST, $_GET & $_COOKIE.

Imagine the following scenario:

if($auth->isValid($_REQUEST['user_id'])
or
if($auth->isValid($_POST['user_id'])

When using the global $_REQUEST how would you know for a fact that you are getting the correct user_id?, as you might already have user_id in $_COOKIE or $_GET, but it's different to the one you are explicitly expecting in $_POST.