MODx (all versions) provides a sample file named ht.access that in most cases, when using the Apache web server, can be renamed or copied to .htaccess to provide for SEO-friendly URL rewrites. Many sites are using other severs, such as Microsoft's IIS and nginx, where .htaccess files don't work.
Whether or not you can use the .htaccess file to make changes to PHP settings depends on the server configuration. If PHP is an Apache module, then it can usually be done. But if PHP is a CGI or FastCGI configuration, then it cannot be used.
Check with your hosting provider's tech support how you should turn it off for your particular server configuration.
Check the phpinfo() link in the Reports -> System Info page to see what the setting really is, both the default and if you've got it set differently locally.
Even after you do successfully turn it off, this won't remove the extra slashes from what's already in the database. You'll have to edit the items and fix it yourself.
-
- 5 Posts
Sorry to re-open this thread but my experience is very similar to this thread.
I have read just about every other post on this topic. My hosting provider copied the php.ini file over to my root. Magic quotes are turned OFF in it.
If i create a phpinfo.php file and run it, it shoes that magic quotes are turned off. But if I view phpinfo within the MODx Reports section, MODx reports that magic quotes is turned ON.
I'm thoroughly confused. How can phpinfo be reporting that magic quotes are ON and OFF at the same time. What do I do from here?
Bryan
The php.ini file needs to be in the same directory as the .php file being run. In the case of the Manager, you need to have a php.ini file in the /manager/ directory, not just the web root.
-
- 5 Posts
That was it! Thank you! Putting the php.ini file in the manager directory resolved the backslash issue.
Unlike .htaccess files, which are for the web server, php.ini files are not inherited by directories. The PHP interpreter engine is a totally separate server application from the web server in this case rather than an Apache module, and it behaves differently in many respects. You need to have the customized php.ini file in each directory where a .php script will be run.
In the case of MODx, that means one in the root (for the main index.php file) and on in /manager/ (for the /manager/index.php file). All other files in the MODx installation are included by these two index.php files, so you don't need one in any of the other directories.
The exception to this would be the case of separate AJAX processing .php scripts; the directories where they are located would also need their own php.ini files. That's another good reason to use a MODx resource with no template and just a snippet with the AJAX processing code as its content. Then it's included through the index.php file as usual, and will be configured via the existing php.ini file in the root.
It is recommended to have these custom files be complete copies of the default php.ini file, then edit the copy to add or modify the desired entries.
Interesting stuff Susan. Thank you.
What do you know about using .htaccess to load the php.ini recursively? My host implemented this across all my sites and removed all the php.ini files from the MODX installs. It seems to work as intended.
<IfModule mod_suphp.c>
suPHP_ConfigPath /home/username
<Files php.ini>
order allow,deny
deny from all
</Files>
</IfModule>
That depends on how PHP is configured; if it's an Apache module then there are many settings that can be controlled through the .htaccess file (these are inherited from parent directories).
If it's a CGI configuration, then Apache hands over the processing of any requested .php files (or rewrites to them) to the PHP interpreter engine. Any directives in the .htaccess files will have no effect, and will most likely just cause 500 server errors. That's why the block you posted is in a conditional block, only being processed if the Apache module is being used.
mod_suphp implements a form of user switching for PHP scripts so they are run as their owner rather than the Apache user. The configpath directive is telling the suPHP module where to go for its ini file. In this case, only the one php.ini file would be necessary. The deny directive prevents any external access to the php.ini files by a URL; only internal file access is permitted, since these don't go through the web server.
So how PHP can be configured depends on how the server is configured to handle PHP.
[ed. note: sottwell last edited this post 11 years, 5 months ago.]
☆ A M B ☆
☆ A M B ☆