Hi, the following lines are present in dynmap 3.0.1 web/standalone/configuration.php, and they cause errors in my apache error log.

$lines = file('dynmap_config.php');
array_shift($lines);
array_pop($lines);
$json = json_decode(implode(' ',$lines));

The errors are simply that dynmap_config.php doesn't exist, which I think is intentional: because it seems to actually want dynmap_config.json? Making the adjustment personally resolves the issue, although the error is non-breaking to the core functionality of the map in the first place.

configuration.php is used when you have login enabled - it allows the configuration returned to be pruned based on the user's login and associated access, and dynmap_config.php is generated in conjunction with that by the server (instead of dynmap_config.json, which would be readable by anyone). I'm not sure about the specifics of your setup, and whether you've copied files to a remote server or not, but the fact that configuration.php is being run suggests your standalone/config.js has been set based on login being enabled.

For an external server without login, standalone/config.js looks like this (assuming file based map):

var config = {
url : {
configuration: 'standalone/dynmap_config.json?={timestamp}',
update: 'standalone/dynmap{world}.json?_={timestamp}',
sendmessage: 'standalone/sendmessage.php',
login: 'standalone/login.php',
register: 'standalone/register.php',
tiles: 'tiles/',
markers: 'tiles/'
}
};

While for external web and login-enabled: true will give you:

var config = {
url : {
configuration: 'standalone/configuration.php',
update: 'standalone/update.php?world={world}&ts={timestamp}',
sendmessage: 'standalone/sendmessage.php',
login: 'standalone/login.php',
register: 'standalone/register.php',
tiles: 'standalone/tiles.php?tile=',
markers: 'standalone/markers.php?marker='
}
};

While the internal web server generates a return value for standalone/config.js that looks like:

var config = {
url : {
configuration: 'up/configuration',
update: 'up/world/{world}/{timestamp}',
sendmessage: 'up/sendmessage',
login: 'up/login',
register: 'up/register',
tiles: 'tiles/',
markers: 'tiles/'
}
};

The web uses this standalone/config.js to discover the URLs for the associated APIs and data - the internal web server generates one at the same path, so this is how the same web UI works for the various configurations. Using an external server AND any of the various SQL implementations for data storage results in config.js pointing the web to scripts appropriate to those other cases (see the other standalone/MySQL_* vs standalone/SQLite_* etc files).

So, the question here is why you have someone hitting standalone/configuration.php when it sounds like your configuration should be such that standalone/config.js is pointing to standalone/dynmap_config.json instead of standalone/configuration.php.

Hi, thank you for the insight into how the web files are managed. Without knowing too much about it, I assumed errors meant there was a configuration problem. But after your response I looked into config.js and it seems to be configured correctly. But I've also peeked into the access logs and I've discovered at least one of the hits to configuration.php is likely a bot. And due to the infrequency of the errors, and the fairly consistent rate of normal map access, it's very likely the others are, too.

Let me ask one more thing before we close this: Assuming I'm never going to enable login, can I move configuration.php out of my file structure? That way I won't get pinged with errors for these rare events.

I would not recommend configuration.php or else you may get other errors. They likely are bot pings and you might be able to suppress those errors but I'm not exactly sure how to do that.

Another solution would be to change the permissions of the configuration.php so that its xx0 so that other has no permissions and doesn't know it exists. Then if the mc user has permissions to view it can use that file when it checks for errors but not random bots

Sorry for not getting back to this sooner. I implemented the permissions change a little before FedUpWith-Tech's response so the apache user couldn't see the file and I've been occupied with other things since. It seems to have cleared the error's reliably so I see issue is resolved.