Not a bug Changing logo causes server error

Member_68162

Active member
Affected version
2.0.0 Beta 4
I uploaded a new logo to styles/default/xenforo/ with the same file name of "logo.png" and now I'm being shown:

error1.webp

error2.webp

in my ACP.
 
It actually looks like you've removed the file, but the recommended action is not to edit the original file (or remove it), but to use style properties to point to a logo file you've uploaded instead.

You can report the specific server error logs separately if they look to be bugs (please search for existing reports of their messages).
 
It actually looks like you've removed the file, but the recommended action is not to edit the original file (or remove it), but to use style properties to point to a logo file you've uploaded instead.
I uploaded a new file (overriding the existing file) with the same name to the styles/default/xenforo folder. I shouldn't be seeing any kind of errors.
 
My point is that we don't recommend that and therefore an indication that one of the core files doesn't contain expected contents is expected. The recommended approach is to point to your own logo path by changing the style properties.
 
My point is that we don't recommend that and therefore an indication that one of the core files doesn't contain expected contents is expected. The recommended approach is to point to your own logo path by changing the style properties.
I tried that and got the same error.
 
Whatever the "Server errors have been logged" message is referring to is nothing to do with changing your logo. You would need to click on that to get more details as to what those errors were.

If you have put the original XF logo back to where it was then you will need to re-run the File health check which, if the files are no longer missing/changed, then the message will go away.
 
Whatever the "Server errors have been logged" message is referring to is nothing to do with changing your logo. You would need to click on that to get more details as to what those errors were.

If you have put the original XF logo back to where it was then you will need to re-run the File health check which, if the files are no longer missing/changed, then the message will go away.
Did you see the screen shots I posted? Uploading the XenForo logo again changed nothing with the error. Uploading a .png file with the same name shouldn’t cause an issue like this.
 
Did you see the screen shots I posted? Uploading the XenForo logo again changed nothing with the error. Uploading a .png file with the same name shouldn’t cause an issue like this.
Yes, it should. The File Health Checker's job is literally to do exactly what you have highlighted.

If you delete or edit core XF files, what you are describing is exactly what is meant to happen.

You need to open the Server Error Log (100% different to the File Health Check) to see what the error message is. You have not shown this in your screenshots.


Fillip
 
Did you see the screen shots I posted?
Clearly I did. I referred to them. The server error log message (the top red banner in your post) is not related to this. I just wanted to make that clear.

If you have put the original XF logo back to where it was then you will need to re-run the File health check which, if the files are no longer missing/changed, then the message will go away.
Did you do this? Re-running the file health check will hopefully now validate that all files contain the expected contents and the second of those two banners in your screenshot will disappear.

I just want to be clear about something. This isn't "an issue" as such. The warning about files changing is a good thing. It's not going to break anything, it's not going to cause you any problems, it's just a clear warning that files on your server have been changed as this could indicate that the changes were made maliciously. It's a security feature.
 
I’ll check the server error log later when I’m at home.

So I am being told that changing any XF image file will cause this “warning”?
 
To put it another way, if an attacker was to gain access to your server and they were able to replace your logo with something malicious, wouldn't you want to know about it?

Ok, it's unlikely, but we have to be somewhat indiscriminate about which files we monitor for changes - hence we monitor them all and if there are changes detected we will tell you about them.

So, yes, changing the XF file itself will cause the warning.

The solution is simple. Upload "mylogo.png" to whichever location you like on the server. Go to Admin > Appearance > Style properties > Basic options and specify the path to mylogo.png there.

There's another clear benefit to this approach too. It means that the file will never get overwritten during upgrades.

The advice to specify the path to your own file, vs replacing the default file has not changed -- this has always been the recommended approach.
 
This is from the server error log. I don't know if it has anything to do with uploading the logo.png file or not, however it occurred at the same time.

ErrorException: Email to xxxxxxxxxxxxxx failed: proc_open() has been disabled for security reasons src/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/StreamBuffer.php:295

Generated by: Unknown account Oct 2, 2017 at 9:00 PM

Stack trace

#0 [internal function]: XF::handlePhpError(2, 'proc_open() has...', '/home/xxxxxxx...', 295, Array)
#1 src/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/StreamBuffer.php(295): proc_open('/usr/sbin/sendm...', Array, Array)
#2 src/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/StreamBuffer.php(58): Swift_Transport_StreamBuffer->_establishProcessConnection()
#3 src/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/SendmailTransport.php(119): Swift_Transport_StreamBuffer->initialize(Array)
#4 src/XF/Mail/Mailer.php(293): Swift_Transport_SendmailTransport->send(Object(Swift_Message), Array)
#5 src/XF/Mail/Mail.php(261): XF\Mail\Mailer->send(Object(Swift_Message), NULL)
#6 src/XF/Job/FileCheck.php(226): XF\Mail\Mail->send()
#7 src/XF/Job/FileCheck.php(105): XF\Job\FileCheck->completeFileCheck(Object(XF\Entity\FileCheck), Array)
#8 src/XF/Job/Manager.php(241): XF\Job\FileCheck->run(7.99999713898)
#9 src/XF/Job/Manager.php(187): XF\Job\Manager->runJobInternal(Array, 7.99999713898)
#10 src/XF/Job/Manager.php(76): XF\Job\Manager->runJobEntry(Array, 7.99999713898)
#11 job.php(15): XF\Job\Manager->runQueue(false, 8)
#12 {main}

Request state

array(4) {
["url"] => string(8) "/job.php"
["referrer"] => string(32) "https://xxxxxxxxxx/index.php"
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}
 
Heh, well, sort of.

When the file healthcheck fails, we send a notification email. It was that notification email that triggered it.

But the issue itself is actually with the server configuration:
proc_open() has been disabled for security reasons
That function will need removing from disabled_functions in your PHP configuration.
 
Back
Top Bottom