Web GUI PHP settings not working after upgrade Apache

Crew,

We have been running ISPconfig3 for a few years with great satisfaction. A few weeks back we upgraded the Debian Jessie webserver. Currently running Debian GNU/Linux 8.3 (jessie), ISPConfig 3.0.5.4p8. and Server version: Apache/2.4.10 (Debian).
The situation:

We had a more or less failed Apache 2.2 > 2.4 upgrade. We had to make a lot of manual changes. The syntax change:

2.2 configuration:

Code:

Order deny,allow
Deny from all

to
2.4 configuration:

Code:

Require all denied

...caused us a lot of work. We managed and all sites are up and running.

The Problem:
When I create a new website using the Web GUI for a new Wordpress site, I encounter no issues until I want to change the post_max_size=128M and upload_max_filesize=128M using the GUI.

I tried using MOD_PHP and adding an Apache snippet:

Code:

php_value post_max_size 128M
php_value upload_max_filesize 128M

I tried adding a PHP snippet for Fast-CGI, CGI, or SuPHP:

Code:

post_max_size 128M
upload_max_filesize 128M

The site does not reflect the changes.
In /var/www/conf/web###/php.ini

I read:

PHP:

; End:
post_max_size= 128M
upload_max_filesize=128M


The directives are added AFTER ;End:, is this correct?

In /etc/apache2/sites-available/sitename.vhost I cannot find any trace of my set php_value.

I even DISABLED PHP for this particular website. But the site was still running just fine. So the PHP control from the web GUI is broken in my setup.

Question:
Can someone set me on the right track to debug this the right way? Currently I'm lost.

 

Til, thank you for your promt reply. But the damage is already done. (Currently running Debian GNU/Linux 8.3 (jessie), ISPConfig 3.0.5.4p8. and Server version: Apache/2.4.10 (Debian).) I'm pretty sure I followed the suggested steps. My thread title might be misleading. I'll change it. Could you please read through my post again?

 

I can't seem to change the title of my post?

Found it. :-D

 

Yes, they do. Not sure why I missed that.

 

Those .err vhost files do contain the Apache directive snippets content. I ran the /usr/local/ispconfig/server/server.sh but I don't see any related error.
(Only ERROR - CA path error, file does not exist:admin/openssl.cnf)
/usr/local/ispconfig/server/lib/config.inc.php:
$conf['log_priority'] = 0; // 0 = Debug, 1 = Warning, 2 = Error

 

. /etc/apache2/envvars && apache2 -t
Syntax OK

 

I think SuEXEC is not doing it's job either.

 

Current mod_suphp config:

Code:

<IfModule mod_suphp.c>
  # <FilesMatch "\.ph(p3?|tml)$">
  #  SetHandler application/x-httpd-suphp
  # </FilesMatch>
  suPHP_AddHandler application/x-httpd-suphp

  <Directory />
  suPHP_Engine on
  </Directory>

  # By default, disable suPHP for debian packaged web applications as files
  # are owned by root and cannot be executed by suPHP because of min_uid.
  <Directory /usr/share>
  suPHP_Engine off
  </Directory>

# # Use a specific php config file (a dir which contains a php.ini file)
#  suPHP_ConfigPath /etc/php5/cgi/suphp/
# # Tells mod_suphp NOT to handle requests with the type <mime-type>.
#  suPHP_RemoveHandler <mime-type>
</IfModule>

 

I suspect that ISPConfig is currently not able to control the correct use and type of PHP (enginge). What part of the (server)config is worth looking at to fix this issue?

 

Crew,

Currently mod_php does not work with a regular Wordpress setup. Using Fast-CGI and a php.ini snippet

Code:

post_max_size= 256M
upload_max_filesize=256M

I got it to work. I'm not sure what caused this issue. This pointed me in the right direction:

For now I'll stick to the fact that there was a ####.vhost.err file present. Renaming this to .vhost and restarting Apache while tailing multiple logs (tail -f logname.log anotherlog.log) showed errors. A old config change caused the creation of an .err file. The GUI does not show this. All following changes won't be parsed.

Feature suggestion: create an indicator icon next to the sitename in SITE > WEBSITE > tab DOMAIN that appears when an .err vhost-file is present.

WebGUI suggestion: Improve the annotation in SITE > WEBSITE > tab OPTIONS. Clarify where directives for a particular PHP engine go.

 

How do I fix mod_php? Should even bother?

 

Till, thank you for your suggestion. I would appreciate if you took the time to read through the thread. You could read I did exactly as you suggested. Using the same procedure I've indeed been able to fix the issue. My sites run fine using FAST-CGI.

What I don't understand is why this won't work using mod_php. When I enable mod_php I should add a Apache snippet correct? Something like:

Code:

php_value post_max_size 128M
php_value upload_max_filesize 128M

 

Thank you. I'll make sure I'll migrate all sites to php-fcgi. And I'll leave mod_php for what it is. Thanks again for the support. Your work and software is very much appreciated!