No entries in map.conf


After installing the plugin, I enabled the "Enable Nginx Map" option and created a new subsite. I expected to get an entry in map.conf, but the file remains empty.

I am running a WordPress Multisites website with subdirectories on Ubuntu 12.04 LTS with Nginx and ISPCofig 3. The subsites in my WordPress site are working.

Any suggestions?


Pierre Roukens

@Pierre Roukens

Can you verify if a map.conf file is created in wp-content/plugins/nginx-helper folder and is writable by PHP?

Also, do you use different linux-user for nginx and php?

I have the same experience on Debian stable using nginx ( & php5 (5.3.18-1~dotdeb.0) with both running as www-data user. An empty maps.conf file owned by www-data has been created in …/wp-content/plugins/nginx-helper/maps.conf.

Of three network sites (one primary, two sub-sites) I’ve uploaded static content for just one, using nginx configured with the recommended basic multisite subdirectory map (i.e., without including the plugin-generated map.conf file) and a blog subdirectory was created (…/wp-content/blogs.dir/3/); however, the maps file remains empty.

Any help will be appreciated!

Thanks! …Murray


Just for clarity’s sake,
does any of you get the map in the textarea on the settings page?
And has any of you enabled logging?
If no, can you enable logging and share the results (log entries/errors)?

That’ll help me diagnose it more precisely.

Thanks for the feedback.

Hi Saurabh,

No, nothing appears in the manual settings textarea, either. I enabled logging (I had to manually create the file because of a write permission error - is that normal?) but it remains empty, too. Finally, I deactivated/reactivated the plugin with the same results.

BTW, for the sake of completeness, I’m using Wordpress 3.4.2.

Thanks, …Murray

Hi Murray,

Both the log file and the map file use identical php functions for creation and modification. So, a write permission error is not normal. Kindly check if both the files have necessary permissions for www-data.

Still, the map should’ve been generated on the settings page, which points to something else. We had foreseen the write permission errors (we faced it on some of our own systems). That is why, we kept the settings area map.

If you have access to the PHP error log, could you share it?

Besides, we have tested this feature a lot and I can’t think of anything that would generate this issue. I tried but couldn’t replicate it.

So, kindly help me out with anything that’ll help me figure this,.

Thanks and regards.

Hi Saurabh,

Thanks for your assistance. By PHP error log, I assume you mean the nginx error log (/var/log/nginx/error.log attached), right? There’s nothing significant in it, nor in the fpm error log (/var/log/php5-fpm.log not attached). I have not changed the error logging setting, which I believe are enabled by default in their respective PHP.ini configuration files.

I tried removing and re-insalling the plugin entirely, after rotating the log files and reloading nginx, but the results remain the same.

Attached, please find a file listing of the plugin directory (nginx-helper.dir) showing that all files are owned and writable by www-data. I even subsequently enabled group write by www-data but it made no difference: the log file has not been created by the plugin.

Also attacheed is a screenshot of the plugin settings admin page (nginx-helper-screen.png) showing there are no map settings presented but there is an error message about log file permissions. Curiously, though, that message does not appear if I uncheck the Enable Nginx Map option.

Thanks again for your help! …Murray

Attachment Link(s):

Hi Saurabh,

Let’s try again to upload those files…


Attachment Link(s):

Hi Saurabh,

Attached, please find one more error log file, this one is the nginx error log for site vhost server.

Thanks, …M

Attachment Link(s):

Hi Murray, In an older version of the plugin, we had a pre-created empty map.conf, which we discarded later so we could isolate write permission errors. The newer version, doesn’t ship with map.conf and nginx.log, any more. Therefore, I feel, if you delete the plugin and its files and do a vanilla install, the file won’t be created and you would get errors.

That being a separate issue, there are no errors and everything seems to be fine. I still can’t fathom why the map is not getting generated on at least the settings page. Since, it would be a tad inappropriate to ask for server access, could you take the following steps and let me know what happens:

  1. Delete the plugin, completely as I've described above. Install a fresh, clean version from Plugins>>Add New via Just so that we have a blank slate and get rid of some legacy issues.
  2. After installing, get inside the Plugins' editor and open nginx-helper.php
  3. Ctrl F to find this function function get_map()
    if ( ! $this->options[ 'enable_map' ] ) {  
  4. Remove the lines above and see if it makes any difference.


It looks like you have some kind of permission issue on server:


May be you are NOT using www-data user to access site over FTP/SFTP. Please check that.

Hi Saurabh,

I did as you asked. First I completely removed the plugin and verified all files were deleted. Just for extra measure, I restarted php5-fpm, nginx, and rotated the log files before re-installing the plugin and editing nginx-helper.php file to comment-out the indicated block. I also touched the map.conf & nginx.log files in the plugin directory and chown’d them to www-data before activating the plugin.

Still, no map data appears in the settings textarea and both the map and log files are empty. I deleted those two files and tried again: The only difference was that the log file is not written, for which an error is displayed; and the newly written map.conf file is empty. All file permissions look alright. /sigh

Thanks, …Murray

Hi Rahul,

Where do you speculate there might be a file permission problem? I have complete root access to this server (both local and remote). All the files in the tree under the server htdocs root directory, including wp-content/plugins, are owned by www-data with permissions u=rwX,ug=rX.

Thanks, …Murray

Hi Rahul,

Correction: permissions u=rwX,go=rX.

Thanks, …Murray

Screenshot showed message “Can’t write on log file” that is why I asked.

Hi Rahul,

It seems that for logging to be enabled, the nginx-helper plugin requires that the nginx.log file exists and does not create it; hence the error message. There does not seem to be a filesystem permission problem per se.

Thanks, …M


Thanks for details. Looks like a bug from us. We will check and fix it asap.

Already noted at:

Thanks Rahul,

That’s just a minor nuisance for me, though. It’s the missing map information that’s really got me stuck.

Thanks, …Murray

Hi guys,

Reading the code, it appears that update_map() function should be called whenever the Enable Nginx map option is selected on the admin settings page or when a new site is added to the multisite network. When I created a new site, I finally saw some output in the plugin’s nginx.log file that I hadn’t seen before (I had only attempted to generate a map for pre-existing sites):

2012-11-09 09:46:56 | INFO | New site added (id 4)

2012-11-09 09:46:56 | INFO | New site added to nginx map (id 4)

2012-11-09 09:46:57 | INFO | Default options updated for the new blog (id 4)

However, the map.conf file remains empty and no map information has ever appeared for me in the textarea on the nginx plugin’s admin settings page, this seems like progress. I suspect there may be a problem with the invocation of the update_map() function (and perhaps others) via the plugin settings admin page.

Hope this helps. …Murray


The get_map function is called right where the setting exists. You can see that in admin/admin.php.

And this is something that we haven’t experienced on any other site (of the 1000 odd ones) that uses nginx-helper (including our own network).

So, shooting an arrow, in dim light, I assume that somehow the function is not able to get to the database table (prefix_blogs). The log entry shows that the function update_map was called, which in turn, first calls the get_map to get the map and then rewrites the map.conf./

For some reason, get_map is returning nothing and hence update_map fails, as well.

To test this, replace

return $rt_nginx_map;  


return 'any random string';  

The random string would show up in the settings, as well as the map.conf.

Now, if that doesn’t happen, then kindly contact me on saurabh dot shukla at rtcamp dot com. If it happens though, kindly check if you have the wp_blogs table in your database. In any case, you can send me an additional admin credentials on the email address and I can look into it personally.