If you are using Apache (the default web server that comes installed with WAMP, XAMPP, and most shared web hosting services), check that you have the Rewrite Engine module (mod_rewrite.c
) installed and enabled.
Some distributions, like WAMP, may not have this module automatically enabled, and you will need to do so manually.
In a shared hosting environment, you may need to have your hosting service do this for you.
If you have shell access to your server, please take the following steps (from Stack Overflow):
sudo a2enmod rewrite
service apache2 restart
You may also, in addition to the above, if it does not work, have to change the override rule from the apache conf file (either apache2.conf, http.conf , or 000-default file).
If you get an error stating rewrite module is not found, then probably your userdir module is not enabled. For this reason you need to enable it.
sudo a2enmod userdir
To read further on this, you can visit this site: http://seventhsoulmountain.blogspot.com/2014/02/wordpress-permalink-ubuntu-problem-solutions.html
Make sure that your system meets the minimum requirements. In particular, you must have PHP 5.4 or higher installed.
If you are sure that you have the Rewrite module enabled and properly configured, make sure that you have your database credentials properly set in config-userfrosting.php
. See Installing UserFrosting for more details.
Currently, UserFrosting only comes with a configuration file for Apache. So, we do not yet "officially" support nginx or IIS (but we hope to soon!)
If you are proficient in IIS or other server technologies, and wish to contribute the corresponding configuration file, please open a pull request - we'd really appreciate it!
In the meantime, there may be a workaround: you can install Helicon Ape, which provides support for Apache .htaccess
and .htpasswd
configuration files in Microsoft IIS. Choose "full server download" when prompted by the Helicon Ape installer.
Assuming your Apache alias maps /project
to C:/WebProject/
, you'll be accessing the installer at http://example.com/project/public/
, but your 404 error will be showing /WebProject/public/index.php
instead.
The problem here is that mod_rewrite
is incorrectly pointing to the directory itself (WebProject
) rather than the alias name (project
).
To correct this, you’ll need to figure out the proper RewriteBase
to use based on your alias and the 404 error. Add a line in /public/.htaccess
after "RewriteEngine On"
:
RewriteBase /project/public/
This line will direct mod_rewrite
to use the Apache alias. Once this is done, you can re-run the installer by going to http://example.com/project/public
again.
imagepng
during installation.Occasionally, people use web hosting services that do not provide the GD library, or provide it but do not have it enabled. The GD library is an image processing module for PHP. UserFrosting uses it to generate the captcha code for new account registration.
If you are having trouble with gd
in Windows, you should first check your php.ini
file to make sure it is enabled. You'll include the GD2 DLL php_gd2.dll
as an extension in php.ini
. See http://php.net/manual/en/image.installation.php.
In Ubuntu/Debian, you can install GD as a separate module:
sudo apt-get install php5-gd
sudo service apache2 restart
For OSX users (Yosemite and Capitan), you might have GD installed but imagepng
isn't available. In this case, you need to upgrade the default version of GD that ships with these versions of OSX. See this answer on StackOverflow for a complete guide.
There is probably an error, but it is not being displayed because your server is returning an HTTP 200 - OK
instead of the error code it is supposed to. You can confirm this by checking in your browser console for the POST request to /install/master
.
See, UserFrosting is built on the principles of REST, which says that we should use the native HTTP status codes when communicating with the server. When you submit something to a UserFrosting application, the server side returns a code such as:
200 - OK
500 - Internal server error
400 - Bad request
403 - Forbidden
404 - Not found
On the client side, UserFrosting uses these HTTP codes to determine what action to take after the response is received. Thus, if it receives HTTP 200 - OK
, it will assume the request was successful. So, thinking that the master account creation was successful, UF tries to forward you to the home page. But when it gets there, UF sees that the master account was in fact not successful, so it takes you back to the registration page, thus making it seem like the registration page just refreshed.
We are not yet sure why some servers are returning the wrong HTTP status code. This problem has been reported on the Slim forums as well. It may be a problem due to caching, buffering, or certain reverse proxy configurations.
Our suggestion for now, if you're having this problem, is to contact your hosting service and explain that the server does not seem to be preserving your response headers correctly.