Source of the Problem

The issue appears to be that when a page is loaded, and the script tries to load one (or more) additional files to perform sub-tasks, the system runs out of allocated memory.

This happens most often on a shared host on an "oversold" site. Your host does not explicitly limit the memory, bandwidth, or disk space you can use. But once your shared server starts to get full, those resources will have to be shared by a number of "unlimited" accounts. At this point, the host will have to apply "hidden" limits to the accounts to keep the accounts from overloading the server. You will start running into memory, disk space, or bandwidth problems, or even have your forum shut down -- temporarily or permanently. Even though you are, therefore, meant to have been offered an "unlimited" service, you have not.

It is important to realize that there is a limit to how much memory a given script can access, and that every host has to have limits like this. The difference is that some hosts let you know in advance what your limits are going to be, and will be able to discuss how you can get more resources if you need them. An oversold host cannot do this, because the limits are variable. The limits are related to how many accounts they place on the same server, how much disk, memory, CPU or bandwidth those accounts use.

In some cases, the host has set this limit very low. So low, in fact, that the package manager cannot load Subs-Post.php to process the BBC tags in the readme file of a mod. If that step is skipped, the script chokes when it tries to load Subs-Package.php, to actually do the install. Processing stops before the package can be checked or installed, and the HTML document does not get created correctly.

How to Solve the Problem

You now have three choices:

1. Ask your host to increase your available memory.
2. Switch to a non-overselling host. There are a large number of those hosts listed in our Hosts and Hosting boards
3. See below for options that you can try (none are guaranteed to work) if you want to stay on your current host.

These hosts may be slightly more expensive than the one that you originally chose, but, as is often the case, you do get what you pay for.

Increase memory allocation externally

You can try and use a .htaccess file to overwrite the memory limit, but if the server controls it (which is probably the case, since SMF tries to set it high enough using ini_set when installing a mod package), than it probably won't work, and you are stuck with the server php memory limit. Using phpinfo() should also tell you if PHP runs in CGI mode or as an Apache module (mod_php). If CGI mode htaccess won't work, if Apache module, use htaccess to set the php memory limit:

• Creating a phpinfo.php file, will tell you your php memory limit.

<?php phpinfo(); ?>

• In .htaccess, you can try to add the following:

php_value memory_limit 64M

• If you add this and get a 500 Internal Server Error, then your host is running PHP in CGI Mode, and you will have to increase the memory_limit in the php.ini file.

memory_limit = 64M

If you are not allowed to have a custom php.ini file, you will have to ask your host to do this.

Increase memory allocation in the file(s)

You can try to increase the memory allocation in the files and functions, directly.

• In /Sources/Class-Package.php, find:

	// If we're using this try to get some more memory.
		@ini_set('memory_limit', '32M');

• Replace with

	// If we're using this try to get some more memory.
		@ini_set('memory_limit', '128M');

• in /Sources/Admin.php, find

// Get one of the admin information files from Simple Machines.
function DisplayAdminFile()
{
	global $context, $modSettings, $smcFunc;

	@ini_set('memory_limit', '32M');

• Replace with

// Get one of the admin information files from Simple Machines.
function DisplayAdminFile()
{
	global $context, $modSettings, $smcFunc;

	@ini_set('memory_limit', '128M');