Category Archives: WAMP Developer Server

Error “Warning: mysql_pconnect(): MySQL server has gone away…”

If you are having a reoccurring problem where Mysql refuses connections with the following error message:

Warning: mysql_pconnect(): MySQL server has gone away in C:\WampDeveloper\Websites\domain.name\webroot\script\file.php on line X

Note that you are using persistent connections. Persistent connections do not automatically close when the script ends, and likely what is happening is either…

  1. That same persistent connection, is correctly reused each time the script runs, but eventually it does reach its maximum run-time value, and is closed by MySQL. And only after your page is refreshed/reloaded and the script runs again, a new persistent connection is created and everything works again (until the next timeout).
  2. Many persistent connections are created, and after MySQL reaches the maximum number of allowed connections, no new connections are allowed until some of the previous connections timeout. Sometimes this is due to a large number of users (100+) all accessing the script, other times this is due to issues and bugs in the script itself (and there can also be some complications when running PHP-FCGI).

To fix this, you have several different options:

Default to Regular Connections

Tell PHP to silently use non-persistent connections even when persistent connections are specified…

Edit php.ini (C:\WampDeveloper\Config\Php\) and update or add this into the [MySQL] section…

; Allow or prevent persistent links.
mysql.allow_persistent=Off

This will close each connection when the script ends, regardless if “mysql_pconnect” or “mysql_connect” is used.

Switch to Regular Connections

Don’t use the persistent versions of PHP functions and methods for MySQL connections. Persistent connections are never recommended, and should only be used in special circumstances (because they tend to just cause connection exhaustion while offering no real performance gains).

Instead of “mysql_pconnect” just use “mysql_connect“. Both functions use the same exact API (i.e., parameters), and you can safely search-and-replace all occurrences of “mysql_pconnect(” with “mysql_connect(” in your script files.

Also note that the above functions are depreciated starting with PHP 5.5, and will be removed from PHP in later versions. If you can, switch to using PDO methods.

Increase Max Connections and Timeout Values

Otherwise, increase the number of allowed connections…

Edit my.ini (C:\WampDeveloper\Config\Mysql\) and add this into the [mysqld] section…

Increase the number of MySQL connections allowed:

max_connections = 151

* The above is the default value.

Depending on the situation, decrease the persistent connection timeout value (so those persistent connections are closed and recycled faster):

interactive_timeout = 28800
wait_timeout = 28800

* The above are the default values, in seconds (8 hours).

These settings might not exist in my.ini, you have to add them into the [mysqld] section of the file.

Note that:

1. These are the default values for each setting… If you put them “as-is”, they will have no effect… As those settings + values, even while they might not be present in my.ini, are already set by default by MySQL for itself on each start-up.

2. These values don’t technically fix anything, they just try to mitigate around some underlining problems with connection timeouts caused by issues in the script. They are temporary patchwork (in most cases).

3. Take care setting these values correctly. max_connections might need to be doubled, and/or the timeout value might need to be lowered to 300 (seconds). But if you increase or decrease these values too much, other issues could start happening.

4. Don’t use these settings if they do not fix anything.

5. You’ll need to restart Apache and MySQL after making changes to my.ini and php.ini.

Installing APC For PHP 5.5

If you need to install and enable the php_apc extension for PHP 5.5 (or 5.6), there is a way to accomplish this. But before you do this, there are a few things you have to be aware of:

  • The last PHP version that had the php_apc extension included in was PHP 5.3.
    * Newer versions of PHP have replaced APC with php_opcache.
  • The last APC release was php_apc 3.1.14, and while it worked with PHP 5.5, it was immediately removed due to some serious memory issues that could not be fixed.
    * php_apc 3.1.14 is not available anywhere, it was removed from all official sources.
  • The only available release of APC is 3.1.13, and while it’s for both PHP 5.3 and 5.4, it’s only non-beta for 5.3 (i.e., not recommended for PHP 5.4).
    * php_apc 3.1.13 will not work with PHP 5.5+.

Having said that, APC has two parts to it… The opcode cache part that compiled and cached script code, and the data cache part that stored key/value pairs (just like memcached).

If your scripts require APC, more than likely they only do so because they use APC’s data cache part. And if you want to run those scripts under PHP 5.5 (or 5.6), the APCu extension fully replaces APC, and is fully compatible with APC’s API.

APCu is the APC extension with the opcode cache part removed (which was the source of all APC issues) and the data cache part cleaned up. APCu has the same exact functions and configuration directives as APC – so it can be used as a drop-in replacement.

Also, from what I’ve gathered, APCu performs even better than memcache/memcached on single server setups (which is the case 95% of the time if you are using a WAMP such as WampDeveloper Pro).

Installing APCu For PHP 5.5

1. Download the latest build of APCu from -
http://windows.php.net/downloads/pecl/releases/apcu/

For PHP 5.5 Standard:

 php_apcu-4.0.7-5.5-ts-vc11-x86.zip

For PHP 5.5 FCGI:

 php_apcu-4.0.7-5.5-nts-vc11-x86.zip

2. Extract out files php_apcu.dll and php_apcu.pdb into the proper PHP version package -

For PHP 5.5 Standard:

 C:\WampDeveloper\Versions\Php\php-5.5.19.0-r1-win32-vc11-standard\ext\

For PHP 5.5 FCGI:

 C:\WampDeveloper\Versions\Php\php-5.5.19.0-r1-win32-vc11-standard-fcgi\ext\

3. Edit php.ini, near end add section:

[APCu]
extension=php_apcu.dll
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
apc.enable_cli=1
apc.serializer=php

3. Save file. Restart Apache.

Assigning a Dedicated IP Address to a Website

There are only several situations where you would need to assign and dedicate an IP address to a website on the web-server’s end.

Under normal circumstances, you can host 100s of websites, each using its own separate domain name and aliases, on the same exact single IP address – without having to assign or use any specific IP address (that is, on the web-server’s end).

Once you assign a dedicated IP address to a website, any requests that come in on that IP address, will return only that specific website, regardless of the domain name used, and you will not be able to host other websites without an additional IP address.

Domain Based Hosting Vs IP Based Hosting

Any URL request made by Browser (i.e., an HTTP/1.1 request) has a “Host” Header in it, that the web-server can read. This “Host” Header specifies the requested domain name.

With the current WampDeveloper Pro configuration, the way it works is that Apache reads that “Host” Header (from the incoming request) to get the domain name, and returns the proper website by matching that domain name to one of the websites’ Primary Domain Name or Domain Aliases. Once the request reaches Apache, no IP addresses are used to select a website.

Using Domain Based Hosting, after you set up DNS for your domain names, everything else is taken care of automatically…

When a request from a Browser is made, the DNS system will resolve the domain name to an IP address, and the request will travel and route though the internet using that IP address, but when it reaches WampDeveloper Pro, Apache will simply read the “Host” Header (that is part of that incoming request) to get the domain name, and will then return the proper website (by matching that domain name with one of the websites).

To set up DNS, using the DNS control panel of your Registrar or DNS provider, assign each domain-name (including the “www” part, the base domain part, and any aliases) an IP address via an “A” record. Then wait an hour for the global DNS system to update.

IP Based Hosting

There are several edge-cases and situations where Domain Based Hosting does not work 100% for everyone:

1. HTTP/1.0 requests do not contain the “Host” Header, which was introduced in HTTP/1.1. Some older or very simple programs, scripts, and bots, that visit or send requests to your website might still use HTTP/1.0 (or they just might make a direct connection without using DNS). In which case Apache will return the default (first loaded) website instead of the correct website.

2. Very old versions of Browsers (e.g., IE6) do not support SNI (Server Name Indication). And when those Browsers make an HTTPS request, since the “Host” Header is only decrypted and read after the SSL connection is established, Apache has no choice but to return the default (first loaded) website’s SSL certificate instead of the proper website’s SSL certificate. And the user is presented with a certificate mismatch warning and/or is prevented (for security reasons) from loading the website by the Browser.

3. Related to #2, aside from IE6, all versions of IE on Windows XP and Server 2003, Safari on XP, and some other earlier versions of other Browsers do not have native support for SNI, relying on the OS’s implementation of it. And Windows XP and Server 2003 did not provide an implementation of the needed system component for SNI.

4. Users, configuration policies, and some installed programs (such as McAfee) are able to disable some SSL and TLS protocol versions (on Windows), or their SNI extension, and occasionally do so for unknown reasons. Any Browser that does not use its own integrated implementation of the needed components will not be able to make an SNI enabled request in this situation.

Assigning a Dedicated IP Address to a Website

Edit the website’s HTTP and HTTPS VirtualHost files.

* Select your website in WampDeveloper’s Websites Tab, click the HTTP and HTTPS VirtualHost button.

Update this:

<VirtualHost *:80>

With this:

<VirtualHost specific.ip.address.here:80>

Save files. Restart Apache.

PHP And Mysql Error ‘TYPE=MyISAM’ With Failure To Install Php Script

If you install an older PHP script or application that was designed to use MySQL 5.1, under MySQL 5.5 or 5.6, this error will either be displayed on-screen or will be logged in the website’s PHP or MySQL error log files.

#1064 – You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘TYPE=MyISAM’ at line …

MyISAM in MySQL 5.5+

The MyISAM storage engine is still available in ALL versions of MySQL, including 5.5 an 5.6 (and can also be used as the default storage engine).

The only things that have changed from MySQL 5.1 is that:

  1. InnoDB is used IF the table type is not explicitly specified when the table is created.
  2. The SQL syntax was changed from "TYPE=" to "ENGINE="

Fixing ‘TYPE=MyISAM’ MySQL Error

Your issue is a result of depreciated SQL syntax being used that is no longer valid in MySQL 5.5+.

MySQL 5.5+ no longer uses keyword "TYPE" to specify the database engine to use for the table (e.g., InnoDB, MyISAM). MySQL 5.5+ uses the keyword "ENGINE" instead.

To fix the broken PHP script or application, edit the files manually, or use an editor like Notepad++, to search and replace in all the *.sql files (or in *.php files if it’s generating the DB dynamically in some function), and change all occurrences of "TYPE=" to "ENGINE=".

Usually you only have to edit 1 SQL or PHP file, that is used to create the database on installation.

Default Storage Engine MyISAM

If your PHP script or application depends on MyISAM (for whatever reason), AND it does not specify the ENGINE type when creating new databases and tables…

Edit MySQL 5.5+’s my.ini file to change MySQL back to using MyISAM by default…

default-storage-engine=MYISAM

Otherwise the InnoDB storage engine will be used.

Other Incompatible Changes

While the majority of the issues will be solved with the above changes, there are also a number of other issues that can come up…

Upgrading from MySQL 5.1 to 5.5

For example, you should replace all occurrences of "TIMESTAMP(N)" with "TIMESTAMP".

Opening the MySQL shell, creating a test database, useing that database, and executing SOURCE C:/path/to/file.sql, will give you a good view of the issues in the SQL file – as it tries to create its tables.

If you import the MySQL data files instead of the SQL dumpfiles, make sure to also run ‘mysql_upgrade‘.

Netbeans “Waiting For Connection (netbeans-xdebug)” Issue

When NetBeans is unable to make a connection with XDebug, the NetBeans IDE will display message “Waiting For Connection (netbeans-xdebug)” at the bottom right corner…

Netbeans_waiting_for_connection

Lets go through the list of things that can cause this issue.

* To save you all the reading, this issue is more than likely your firewall or anti-virus software blocking NetBeans from establishing a connection, or NetBeans attempting to connect with XDebug on something other than IP 127.0.0.1 (through a LAN or Public IP, or on the IPv6 interface) and port 9000.

Check NetBeans Project Configuration

After configuring XDebug and setting up NetBeans to use the same local web server, check the Project settings to make sure everything is correct:

NetBeans-XDebug-Run_Configuration

NetBeans-XDebug-Sources

Check XDebug’s Loading and Configuration

Make sure XDebug has actually been loaded by PHP, and it’s settings are correct.

phpinfo_xdebug

The important settings are these:

xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_autostart=0
xdebug.remote_connect_back=0

This tells XDebug to enable connections to it, and to send the data back to 127.0.0.1:9000, which hopefully NetBeans is listening on.

Check Apache’s, PHP’s, and Website’s Error Logs

Check the specific website’s PHP error log file for any clues such as “unable to load module …” and “Call to undefined function …”.

Also check the general Apache and PHP error log files for the same messages or other errors.

* The PHP error log file will not exist if: you are using PHP-FCGI (in this case the errors are logged to each website’s individual PHP error log file), and/or no errors have been generated so far.

Check Browser

Does the URL http://www.example.com/ (substitute in your domain name) come up without any issues?

If not, then possibly:

  • The Browser (or OS) is configured to use a Proxy which resolves the website’s Domain Name to somewhere else (i.g., not to 127.0.0.1).
  • The Windows Hosts file might have the website’s Domain Name to IP resolve line missing, or using an IP other than 127.0.0.1.

Make sure NetBeans is closed, and restart Apache, don’t start NetBeans. Does the full query URL come up without any issues?

http://www.example.com/index.php?XDEBUG_SESSION_START=netbeans-xdebug

If not, then possibly:

  • The website’s VirtualHost files or .htaccess file have redirect or rewrite rules that are breaking the request.

Check Rewrite and Redirect Rules

NetBeans will use a URL with a query similar to this:

http://www.example.com/index.php?XDEBUG_SESSION_START=netbeans-xdebug

Possible .htaccess and VirtualHost mod_rewrite rules that use, parse, and/or redirect requests based on the query string could break the request.

Clear Previous Sessions and Cache

Stop Apache, and delete all files in PHP’s and XDebug’s temporary folders:

C:\WampDeveloper\Temp\
C:\WampDeveloper\Temp\xdebug\

This will clear out any previous sessions so you can start with a fresh PHP session store and a fresh XDebug data store. Sometimes these temp files get corrupted, or don’t get cleared out properly, and things get hung up.

Check 127.0.0.1:9000 Bindings

Make sure that another process or program has not taken 127.0.0.1:9000.

Close NetBeans, stop Apache, wait a minute for all the Listeners to clear out, then open the command line (admin mode), and execute:

netstat -o -n -a | findstr 127.0.0.1:9000

If it finds a Local Address Listener (which is the 1st address, not the 2nd), you can cross-reference the PID (Process ID #) shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).

Whatever this turns out to be, it needs to be stopped and disabled, or re-configured to not take port 9000.

* The other option is to reconfigure both NetBeans and XDebug (php.ini) to use another port.

Check NetBeans Listeners and Connections

If the above is clear, verify that NetBeans is:

  1. Listening on all interfaces of IPv4 (0.0.0.0) and IPv6 (“[::]“) with port 9000.
  2. Taking a connection on 127.0.0.1:9000.

Start Apache, open NetBeans, load your project, make a debug point in the PHP code, and click to Debug it.

Once this is started, NetBeans should create the proper Listeners, and if everything is correct, start talking back and forth with Apache (if PHP is type:Regular) or PHP (if PHP is type: FCGI) between port 9000 and some random port of the Apache / httpd or PHP process…

netstat -o -n -a | findstr :9000

A good debugging connection between NetBeans and Xdebug looks like this:

  TCP    0.0.0.0:9000           0.0.0.0:0              LISTENING       5424
  TCP    127.0.0.1:9000         127.0.0.1:50821        ESTABLISHED     5424
  TCP    127.0.0.1:50821        127.0.0.1:9000         ESTABLISHED     6604
  TCP    [::]:9000              [::]:0                 LISTENING       5424

It shows that NetBeans (PID 5425) is Listening on all IPv4 addresses (0.0.0.0 includes 127.0.0.1), and that there is a connection Established to and from Apache / httpd (PID 6604).

* Names of processes are shown in Windows Task Manager, Processes Tab (click button: ‘Show processes from all users’ at bottom so it displays everything).

The important part here is that NetBeans is at least Listening on 0.0.0.0:9000. Otherwise, its settings are wrong, or something (usually firewall and anti-virus software) is preventing it from starting that Listener.

Is NetBeans Using a Non-Default Port (not 9000)?

If NetBeans is not using the correct port (9000), update NetBeans settings:

Tools, Options, PHP, Debugger Port

Or update XDebug’s php.ini settings to match that port.

Is NetBeans Only Listening On IPv6?

If there is no proper IPv4 (0.0.0.0:9000 or 127.0.0.1:9000) Listener, verify that:

NetBeans, and Java, have NOT been configured to prefer (use) IPv6 over IPv4:

For NetBeans -

Global Configuration File:

C:\Program Files\NetBeans 8.x.x\etc\netbeans.conf

Local Configuration File (might not exist):

%AppData%\Roaming\NetBeans\8.0.1\...

In option “netbeans_default_options” make sure it’s not set to prefer IPv6:

-J-Djava.net.preferIPv6Stack=true

If it is, change it to:

-J-Djava.net.preferIPv4Stack=true

For Java -

Open:

Control Panel - System - Advanced System Settings - System Properties - Advanced tab - Environment Variables

Check the environmental variables list for variable: _JAVA_OPTIONS

If it exists and contains:

-Djava.net.preferIPv6Stack=true

Change it to:

-Djava.net.preferIPv4Stack=true

Also open the Java Control Panel, and check if there are any Java Runtime Parameters (Java – View) or Proxy Settings (General – Network Settings) listed.

Control Panel - Java

* After these changes, reboot.

xdebug.remote_host

Make sure that NetBeans is working with IP 127.0.0.1, rather than the LAN IP or Public IP!

Otherwise, XDebug’s “xdebug.remote_host=127.0.0.1” will need to either be updated with the specific IP, or “xdebug.remote_connect_back=1” used to tell XDebug to connect back to ANY source IP…

http://xdebug.org/docs/all_settings#remote_connect_back

“If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER['REMOTE_ADDR'] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.”

xdebug.remote_autostart

http://xdebug.org/docs/remote#browser_session

“When the URL variable XDEBUG_SESSION_START=name is appended to an URL Xdebug emits a cookie with the name “XDEBUG_SESSION” and as value the value of the XDEBUG_SESSION_START URL parameter.”

If there is an issue with cookies being set, “xdebug.remote_autostart=1” must be used…

“Normally you need to use a specific HTTP GET/POST variable to start remote debugging. When this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.”

Check Firewall and Anti-Virus Software

If the NetBeans project settings are correct, the website work in your Browser, the IPv4 Listener is good, it’s possible that your Firewall and/or Anti-virus software has decided to block the Java based NetBeans program from making connections, and possibly also Apache and PHP, and/or port 9000.

You’ll have to either shut them down, or go through their current lists of blocked and quarantined programs (NetBeans, Apache / httpd, PHP) and blocked ports (9000).

And also create rules and whitelists for NetBeans, and for port 9000.

I would start with McAfee and Kaspersky, by just turning then off (some of these don’t fully turn off and have to be uninstalled). Then check Windows Firewall the same way.

Also, just to cover the last crumb, right-click on the php_xdebug.dll file, select Properties, and if its listed as “Blocked”, click to unblock it:

C:\WampDeveloper\Components\Php\ext\

Other

For best results while figuring out the cause of all this, to bypass all the external browsers, in the NetBeans Project’s Properties, Browser category, switch from ‘Default’ or ‘Chrome’ to “Embedded WebKit Browser”.

Some questions to ask yourself -

1. Have any other Apache or PHP extensions been loaded? Apache’s mod_security could easily block this (it’s never loaded by default in WampDeveloper Pro). Some extra PHP extensions might also conflict with XDebug.

2. Where there any changes made to PHP’s php.ini, aside from introducing the XDebug section? And also Apache’s configuration?

3. Has the website’s VirtualHost files been modified with php.ini overriding settings (“php_value” or “php_admin_value” setting “xdebug.remote_host=some.where.else”), other configurations, or access restriction?

4. Has the website’s .htaccess file been modified with php.ini overriding settings (as above), other configurations, or access restriction?

5. Where any extra .htaccess files placed into any of the parent folders (from the website), all the way up to C:\?

Configuring NetBeans 8 with XDebug Connection on WAMP

Configuring and connecting NetBeans with XDebug to run and debug local PHP projects and scripts is very simple.

These instructions will work for any WAMP, such as Xampp or WampServer, but are specific to WampDeveloper Pro (as it already provides everything needed).

Load and Configure PHP’s XDebug Extension

Open PHP’s configuration file: php.ini.

Find and un-comment the XDebug section that already exists near the end of php.ini, by removing the “;” from each settings line. Save file. Restart Apache.

[XDebug]
; Note that profiler is enabled separately.
zend_extension="C:\WampDeveloper\Components\Php\ext\php_xdebug.dll"
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_autostart=0
xdebug.remote_connect_back=0
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_name=cachegrind.out.%s.%t
xdebug.profiler_output_dir="C:/WampDeveloper/Temp/xdebug"
xdebug.trace_output_dir="C:/WampDeveloper/Temp/xdebug"

The provided XDebug settings will work with the NetBeans IDE out-of-the-box. The configuration uses as many default values as it can, and nothing needs to be changed as long as NetBeans is on the same system WAMP is on.

Create NetBeans Project

We will set up a project that uses the www.example.com website, and it’s contents (the index.php file).

New project:

PHP Application with Existing Sources

Sources Folder:

C:\WampDeveloper\Websites\www.example.com\webroot\

* Changed from the pre-filled default to update to the website’s DocumentRoot folder.

Project Name:

TestProject

PHP Version:

PHP 5.6

Runs As:

Local Web Site (running on local web server)

Project URL:

http://www.example.com/

* Changed from the pre-filled default of “localhost” to website’s Primary Domain Name. And removed the “/webroot” part, as it’s not a URL, it’s the website’s DocumentRoot folder.

Index File:

index.php

Finish Project.

Start Debugging

In NetBeans, open the index.php file, and set a debug break-point on any PHP line.

* Use “<?php” instead of “<?” for your PHP code unless you’ve enabled the NetBeans option to use short-tags in the project.

Make sure Apache is running, and click the IDE’s “Debug Project” (not “Run Project”) icon.

It will open the system’s default Browser to URL:
http://www.example.com/index.php?XDEBUG_SESSION_START=netbeans-xdebug

That “XDEBUG_SESSION_START” part tells PHP to start XDEBUG for that request, and it will provide NetBeans the debug data by sending it to the specified IP and Port (in php.ini) / which is the address NetBean’s XDebug client is listening on.

You should be able to now step through the PHP code using the NetBeans IDE!

Issues

If for some reason your PHP code can’t handle the query string, you can enable “xdebug.remote_autostart=1” (php.ini) to auto start debugging for all requests. But this will slow everything down further, and also generate much more data.

Once done, make sure to stop the Debugging process so everything get’s cleared out.

If there are any issues with Apache and PHP request timeouts, these can always be increased.

And if any odd issues start happening with either the Browser or the XDebug sessions:

  • Make sure to stop NetBeans Debugging.
  • Go into the Browser’s settings, and clear out the entire History, Temp files, and Cache, then close it.
  • Restart Apache.

Also, it’s best to not use IE as the default Browser for NetBeans, but to change to using the “Embedded WebKit Browser”, via the Project’s properties.

PHP “Call to undefined function mb_detect_encoding” Error

This error is always related to PHP being unable to load the php_mbstring extension, because of some issue with the “php_mbstring.dll” file, or the environment…

Fatal error: Call to undefined function mb_detect_encoding() in Wamp\phpMyAdmin\libraries\php-gettext\gettext.inc on line 177

It usually happens when you try to access phpMyAdmin.

Update PATH and Reboot OS

After installing WAMP, or using a new version of PHP, make sure to reboot/restart the system. This will:

  • Propagate the proper PATH changes that includes the location of these files.
  • Clear out any previous DLL versions that might be still loaded by the OS.

Unblock php_mbstring.dll

Go into PHP’s \ext folder, right-click on file “php_mbstring.dll”, select Properties, and at the bottom make sure the file not listed as “Blocked”. If it is, click “unblock”.
C:\WampDeveloper\Components\Php\ext\

Restart Apache.

Test Dependencies

Test for the presence of all the DLLs the php_mbstring.dll extension depends on…

Open the command-line, change to PHP’s directory, and run PHP’s deplister:

cd Components\Php
deplister ext\php_mbstring.dll
php5ts.dll,OK
MSVCR110.dll,OK
KERNEL32.dll,OK

* This will only work on some newer versions of PHP that have “deplister”.

If you see a message about MSVCR110.dll (or some similar named DLL) missing / not-found, your system is missing this run-time:
Visual C++ Redistributable for Visual Studio 2012 Update 4

You’ll need the 32 bit version: vcredist_x86.exe

This run-time is included on most current and updated OSs, but some non-updated OSs only have the 2008 version.

Reboot.

Check php.ini

Check php.ini to make sure extension “php_mbstring.dll” is being included/loaded…
C:\WampDeveloper\Config\Php\php.ini

Locate, and make sure this extension line is un-commented (no ‘;’ in front) -
extension=php_mbstring.dll

It’s loaded by default under WAMP, unless the PHP version’s php.ini was modified.

Restart Apache.

Check for older DLLs

It is possible that some PHP DLLs, from other PHP or WAMP installations, exist on your system, which should be removed.

Search your PC for files: php5ts.dll, php5.dll, php_mbstring.dll

The found location will most like be:
C:\Windows\system32

In the location you find any of the above files, you might also have a bunch of other php*.dll files that need to be deleted.

* Don’t delete anything within WAMP’s folder:
C:\WampDeveloper\

Reboot.

Check Log Files

If nothing else helps, check the Log files again -

A. Apache’s general error log – Logs\Apache\httpd.host.errorlog.txt

B. PHP’s general error log – Logs\Php\errorlog.txt (if exists)

C. And if this is specific to a website, the website’s error logs -
Logs\Websites\domain.name\http.phplog.txt
Logs\Websites\domain.name\http.errorlog.txt

In the case of http://localhost/phpmyadmin or http://127.0.0.1/phpmyadmin , that “domain.name” would be “serverhost”.

Enabling Zend Guard Loader for PHP 5.4, 5.3, or Zend Optimizer for PHP 5.2

Some PHP scripts and apps require the Zend Guard Loader or Zend Optimizer to be able to run, as their code has been encoded either to obfuscate reverse-engineering or to be licensed.

Normally, to install and use Zend Guard Loader or Zend Optimizer (to decode obfuscated PHP code, or run licensed scripts) you would need to: locate and download the proper package, match it to your PHP version and build type, and configure php.ini to set up and load the extension. Otherwise, an error message similar to “Zend Optimizer | Zend Guard Loader not loaded or installed” will be shown, such as this one:

PHP extension “Zend Optimizer” or “Zend Guard Loader” is not loaded. The required run-time support is not installed or properly configured to run PHP scripts encoded by Zend Encoder and Zend Guard.

Installing and enabling Zend Guard Loader and Zend Optimizer is made easy with WampDeveloper Pro, which includes the last good version of each Loader, their full configuration, and their matching PHP versions and types:

  1. Zend Guard Loader for PHP 5.3 FCGI.
  2. Zend Optimizer (Loader) for PHP 5.2 Regular.

Zend Guard Loader for PHP 5.4 and 5.3 FCGI

The last version of Zend Guard Loader is v3.3, and it was released for PHP 5.4 and 5.3 FCGI only (e.g., there is no “Thread Safe” build for regular PHP).

1. In WampDeveloper’s Components Tab, click the link to download the latest PHP 5.4 or 5.3 FCGI version, and extract the ZIP into folder:
C:\WamDeveloper\Versions\Php\

2. Open and edit (via notepad) PHP 5.4′s or 5.3′s php.ini file:
C:\WampDeveloper\Config\Php\php-54.ini
C:\WampDeveloper\Config\Php\php-53.ini

Near the bottom, find section “[ZendGuardLoader]“, un-comment it as such:

[ZendGaurdLoader]
; ONLY PROVIDED UNDER PHP-FCGI
; MUST BE LOADED AFTER Ioncube, AND BEFORE XDebug
zend_extension="C:\WampDeveloper\Components\Php\ext\ZendLoader.dll"
zend_loader.enable=1
zend_loader.obfuscation_level_support=3
zend_loader.license_path=

Save file.

3. In WampDeveloper's Components Tab, select PHP's 5.4 and 5.3 Subscription Channel:

Channel:  Stable
Bits:     32
PHP Type: FCGI

Then check-mark to use the proper Apache, PHP (FCGI), and MySQL versions. And click: "Switch To Selected Versions".

4. After starting Apache, check the http://serverhost/phpinfo.php page:
with-zend-guard-loader-php-53-fcgi

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.3.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies

zend-guard-loader-php-53-fcgi

Zend Guard Loader

Zend Guard Loader    enabled
License Path         no value
Obfuscation level    3

Zend Optimizer (Loader) for PHP 5.2

The last version of Zend Optimizer (Loader) is v3.3.3, and it was released for PHP 5.2 only (e.g., there is no "Not Thread Safe" extension for FCGI PHP).

1. In WampDeveloper's Components Tab, click the link to download the latest PHP 5.2 Regular version, and extract the ZIP into folder:
C:\WamDeveloper\Versions\Php\

2. Open and edit (via notepad) PHP 5.2's php.ini file:
C:\WampDeveloper\Config\Php\php-52.ini

Near the bottom, find section "[Zend Optimizer]", it should already be un-commented as such:

[Zend Optimizer]
; this will make Apache crash/unstable if used with APC
zend_extension_ts="C:\WampDeveloper\Components\Php\ext\ZendOptimizer.dll"
zend_optimizer.optimization_level=0
zend_optimizer.enable_loader=1

Save file (if you made any changes).

3. In WampDeveloper's Components Tab, select PHP 5.2's Subscription Channel:

Channel:  Legacy-PHP52
Bits:     32
PHP Type: Regular

Then check-mark to use the proper Apache, PHP (FCGI), and MySQL versions. And click: "Switch To Selected Versions".

4. After starting Apache, check the http://serverhost/phpinfo.php page:
with-zend-optimizer-loader-php-52

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

zend-optimizer-loader-php-52

Zend Optimizer

Optimization Pass 1     disabled
Optimization Pass 2     disabled
Optimization Pass 3     disabled
Optimization Pass 4     disabled
Optimization Pass 9     disabled
Zend Loader             enabled
License Path            no value
Obfuscation level       3

Zend Optimizer's "optimization" has been disabled, as we only want it's "decoding" (loader) part.

Display Country Stats In Awstats By Using GeoIP

There are two different ways to get country information displayed in Awstats.

Use Reverse DNS Loopkups

The simplest way to display country stats in Awstats is to enable reverse DNS lookups for each IP address, which Awstats can attempt to parse the country info out of.

This method has two problems, the reverse DNS loopkup: 1) will greatly slow down the update process (5x-10x), and 2) is not very accurate (you’ll get allot of “unknowns”).

1. Edit your website’s awstats configuration file (via Notepad):
C:\WampDeveloper\Tools\awstats\wwwroot\cgi-bin\awstats.domain.name.conf

Update -

# Possible values:
# 0 - No DNS Lookup
# 1 - DNS Lookup is fully enabled
# 2 - DNS Lookup is made only from static DNS cache file (if it exists)
# Default: 2
# 
DNSLookup=1

2. Delete old awstats data files:
C:\WampDeveloper\Tools\awstats\wwwroot\data\*

3. And in URL /stats, click to “Update now”.

Use AWStats GeoIP Plugin

To get more accurate and faster country results in Awstats, use its GeoIP plugin…
http://awstats.sourceforge.net/docs/awstats_contrib.html#geoip

1. Install the Perl “Geo::IP::PurePerl” module:

Open command-line and execute -

perl -MCPAN -e shell;
install Geo::IP::PurePerl
exit

2. Download GeoIP database:
http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz

Extract/place GeoIP.dat file into folder -
C:\WampDeveloper\Tools\GeoIP\

3. Update awstats configuration file for website:

Edit your website’s awstats configuration file (via Notepad) -
C:\WampDeveloper\Tools\awstats\wwwroot\cgi-bin\awstats.domain.name.conf

Load plugin GeoIP (uncomment and update line) -

LoadPlugin="geoip GEOIP_STANDARD C:/WampDeveloper/Tools/GeoIP/GeoIP.dat"

Save file.

4. Delete old awstats data files:
C:\WampDeveloper\Tools\awstats\wwwroot\data\*

5. And in URL /stats, click to “Update now”.

You will have to periodically re-download the database file (which can be automated via Windows Task Scheduler and wget). Also, it’s the free version of MaxMind’s GeoIP offering, how often it’s updated is unknown.

* We are using “Geo::IP::PurePerl” instead of “Geo::IP” because the later depends on additional GeoIP C libraries that are not provided (extra steps would need to be taken to build/compile them).

How To Access Local Website from Internet

The sites work fine on local host, but not on the internet.

Most WAMP Servers such as WampDeveloper Pro accept all incoming connections by default. Even when a request comes in for an unknown website (i.e., the domain name or IP address is not assigned to any website), Apache is configured to return the default website – localhost (the 1st Virtual Host loaded).

If you are unable to make a connection from the internet to your website, then the request did not reach Apache.

When this happens, Chrome (browser) displays “This webpage is not available” message, and clicking on Details shows Error code: ERR_CONNECTION_TIMED_OUT

this-webpage-not-available

IE (browser) produces a more generic “Internet Explorer cannot display the webpage” message, without any specific error code…

ie-cannot-display-webpage

The most common cause of this are:

  1. Local Firewall software such as McAfee, Norton, and Windows Firewall blocking incoming port 80 and 443 requests.
  2. Bad or missing port-forward rules in the Router.
  3. Router settings blocking internet traffic via internal firewall or configuration.
  4. Network firewall or appliances dropping incoming port 80 and 443 requests.
  5. The ISP blocking incoming port 80 and 443 requests.
  6. Changing IPs (both the LAN IP and Public IP), and/or bad DNS records for domains.
  7. Within LAN or Corporate Network, local network proxy settings that are taking the domain-name resolve to somewhere else.

To troubleshoot the issue -

1. Delete all auto-created Windows Firewall rules for “Apache” or “HTTPD”. Create general rules to open port 80 and 443 TCP. Once Apache is started again, when notified/prompted by the firewall, click to unblock Apache.

Also turn all other firewall and anti-virus software off when testing everything… McAfee, Norton, Kaspersky, etc.

2. Access the Router via URL: http://lan-ip.of.router/, and once in, go over it’s setting to make sure it’s not blocking internet traffic.

Then remove all port-forwarding rules, and create the proper rules to forward all WAN:80 and WAN:443 traffic (internet requests) to LAN:80 and LAN:443 (the LAN IP of server).

The Public IP will be assigned to the first device connected to the ISP (which is usually the Router), and that is the reason why the Router needs the proper port-forwarding rules – so that it can forward incoming internet traffic requests to the proper LAN system.

3. When testing this, bypass DNS and domain-names by using the IP address directly:

A) Assigning both the Public IP address and LAN IP address as Domain Aliases of a website.
B) Turning off Redirects from Aliases to Primary Domain Name.
C) And just use the Public IP address, as URL: http://public.ip.address/, to access your website.

4. Verify that you are using the right Public IP and LAN IP addresses. These IPs can change time to time.

5. Also, test the connection from another LAN system via URL:http://lan.server.ip.address/ and http://computer-name/. If this is not working, there is an issue within the local network.

Notes

Being able to successfully ping the Public IP will tell you nothing about the situation… Pings work differently from HTTP connections. If a ping comes back, all that signifies is that the Router settings have pings enabled, and your Router is able to ping you back.

If Apache is running, then it was successful in binding to port 80 and 443, and it’s not a problem with another web-facing service or application (like Skype) taking these ports.

Enabling Online and Internet Access of Websites For WAMP Server

Accessing Websites on a Local Network (LAN) Web Server