I know this may be a general question, but what exactly goes into scaling for all the users you will encounter, even if not in the next few months? I did some research and most of what is done is server side, with caches and other similar stuff. Any points in the right direction would be helpful.
"Even if not in the next few months" smells like premature optimization. Don't do that:
It's not worth it. Many people, when realizing a project, believe that their project will be the second Facebook. Then they release it, and then they notice that ten visitors per month is the best they can do. Spending less money and time on optimizing for further scalability and more time thinking about the project itself would help.
It's like with bottlenecks and profiling: you always have an impression that you know perfectly well where the bottleneck is, and in most cases, you discover that you were wrong when profiling. Do your application first. See how is it used. Profile it. Gather BI data. Gather performance metrics. Analyse it. Check if your analysis was right. Make the predictions about the future, based on your analysis, then optimize for scalability what you really need to optimize.
For example, a scalable web application must be able to be hosted on several servers. The last project I've done for my customer was intended to be scalable. There was a choice: either we spend 1.5 months more in order to make the web app work on several servers, or the customer buys a high quality server (one machine only) and the web app is hosted on this machine only. It was much less expensive to buy an expensive server, counting both the direct cost (price of the server vs. price of 1.5 months of work) and the long term savings (power consumption of one high quality server vs. power consumption of several low-end servers). Now the app is running for a few months, and according to the metrics, if there would be a problem with scalability one day, it would concern in first place the database, and in second place the network infrastructure (switches, routers, etc.).
Now, an application may be more or less scalable on several points:
Database: according to my personal experience, most scalability-related problems come from the database. Hopefully, there are plenty of ways to make the database scalable for every industry-grade database engine, and even before that, there are plenty of ways to improve the database structure and to optimize the queries. Caching helps too.
Network: bandwidth can be a real issue in some configurations, and sometimes you can't do anything about it without doing expenses you can't afford. To avoid being blocked on this level, you can optimize the visual design of the website in order to have less images or better compressed images, optimize the layout of the page, reduce the HTTP requests (through CSS sprites), reduce the quantity of HTML code sent (through AJAX), etc. HTTP compression is a must-have. Browser caching too, but your metrics may show that many clients have an empty cache.
CPU and memory usage: porting an application to be hosted by several servers can be painful too, both on infrastructure (hardware) level and on application (software) level. To avoid this, use extensive caching and profile the application, removing progressively the bottlenecks.
Scalability is very much language agnostic, so there is no PHP specific thing for it. Key factor is to have decoupled subsystems, communicating via language agnostic protocols (so for example if you have to call webservice from your PHP code, don't use PHP's
serialize, but rather JSON, even if both components are currently both implemented in PHP). This will allow you to replace components with other alternatives, perhaps developed in other technologies.
Worrying about scalability now is probably not worth it: if your project takes off and hits the mark from where you cannot scale by adding more hardware, you'll have enough cash rolling in to fund more thorough measures; if it doesn't, then any effort you make now is a waste of your time and resources.
That said, there are a few things you can and should do to keep your application maintainable, and if you follow these guidelines, factoring in scalability will be much easier later on in the game. An ideal solution will allow you to swap out the entire data storage code with only minimal changes to the program logic and no changes at all to the presentation code.