so I have a basic out of the box wordpress installation setup on my instance of a ec2 AMI server. I want to set up wordpress logging. I checked that logging is set to true in my wp-config.php file, and I am expecting a standard debug.log file to show up in wp-content. However this is not happening. Are the errors being piped somewhere else? Could it be that that I am missing some small configuration detail (that usually is the case.) I'm not sure what is wrong. Thank you for your time and help.
Edit: so now I can see that the PHP error log is in the logs folder, accessible from the root directory by default. However, what is still confusing is that I want to be able to route my wordpress errors to the logs that exist, or perhaps just set up my own debug.log file in the existing log directory. I'm reviewing wordpress logging and PHP ini stuff, but I cannot generate a log file. Any help would be greatly appreciated.
I use this plugin in all Wordpress developments. You simply create a file called php-error.log in the root of your Wordpress install, set a few lines in wp-config (instructions after activating plugin in dashboard), and your log will also automatically appear in the dashboard.
http://wordpress.org/plugins/error-log-monitor/
Related
Ubuntu 20.04
Apache 2.4.41
phpmyadmin 4.9.5deb2
I can log in to phpmyadmin and see the main page where the databases are listed in the left-hand panel. But I get an error message. Using F12, I see the following error:
Failed to load resource: the server responded with a status of 403 (Forbidden) config.js:1
There is a config.js file under /usr/share/phpmyadmin/js. There are other js files in that folder that are included in the sources listed in the browser (again, using F12).
I confirmed that the config.js file has read permissions set for everyone. All the js files in that folder have the same permissions set.
I also confirmed that /etc/apache2/conf_enabled/phpmyadmin.conf links to /etc/apache2/conf_available/phpmyadmin.conf and that links to /etc/phpmyadmin/apache.conf. Neither this apache.conf nor /etc/apache2/apache2.conf deny access to config.js.
When I delete config.js, I do not get the error BUT I get other errors concerning functions that are contained in that config.js (like "Uncaught ReferenceError: isStorageSupported is not defined."). This tells me that the forbidden file is indeed this file. I renamed it and created a new empty config.js - still get the same forbidden error(fwiw).
We've been using phpmyadmin on this server since April. The error has cropped up in the last couple weeks. When I ssh'd into the server this week, it displayed a message that it needed restarted to make updates. I did not know there were auto-updates going on. I restarted, which did not help the problem. Then I updated and upgraded everything but still no help. I uninstalled (remove and purge) and installed phpmyadmin, but still no help.
My next step would be to upgrade phpmyadmin to the latest stable using a different repository (the debian repo is a little behind). But I thought I'd ask here because I have a feeling that might not help either.
I'm thinking that something changed in the server stack that isn't allowing the config.js file to be read; I just have no idea what that would be. Has anyone else seen this or something similar?
I implemented a band-aid: I copied the /usr/share/phpmyadmin/js/config.js file to config.1.js. I edited the code in /usr/share/phpmyadmin/libraries/classes/Header.php to use config.1.js instead of config.js.
No error now!
But I don't like this answer because it doesn't tell me what the original source of the problem is and how to keep it from happening again.
I have a dedicated server running Linux/Apache with cPanel. On one of my website's users are able to register and upload images.
However, over the last few days, i have received complaints that users cannot upload any media. When I check the /images/ directory I see that the /temp/ folder is missing.
So I re-created it and set the permissions to 0777.
Once that is completed all works fine. But I cannot understand why the directory is being removed. No one else has access to the site and I do not see anything in my error logs that show anything unusual.
Any ideas why this may happen?
Thank you
You need to check your PHP Script has code to unlink(dir) or Something
and Check cron list whether you have added any CRON to remove the TMP folder.
for Write permission 755 is enough If you are using Fcgi php handler, cgi, dso. Have a try 755 permission with one of the listed Handlers.
I have set up ubuntu server on an old pc with webmin as well. I am not sure what was going on but i restarted the server and when it boots it now get this when Apache tries to start.
* Starting web server apache2
apache2: Syntax error on line 237 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/sites-enabled/000-default: No such file or directory
Action 'start' failed.
The Apache error log may have more information.
I have checked this file on this line and it looks like this:
# Include the virtual host configurations:
Include sites-enabled/
I have removed Apache and re installed it but not sure why it still fails.
As also answered by Qben, the issue was an invalid symlink in the sites-enabled folder. Removing the broken symlink and adding a valid one will fix the issue.
You do not have a default site enabled:
/etc/apache2/sites-enabled/000-default: No such file or directory
site-enabled should contain symlinks to files in site-available and I guess your 000-default symlink does not link to a real file in site-available.
I guess this Ubuntu guide might be of interest for you.
One of the reason may be that you might have some site that is not enabled.To check that
Go to /etc/apache2/sites-enabled
Out of many/some [sitename].conf files , one/some may be crossed
Delete those found crossed
Restart apache server
sudo service apache2 restart.
Hope this has helped you , but may be some other reason too. Thank you.
I have been put in charge of an Ubuntu 13 server installation. Apache is configured to use /var/www as the default directory which is correct. The issue is that it seems there is a fallback directory configured that points to /usr/share. So if I type into a browser (www.address.com) it will serve the documents out of /var/www, but if I know the name of a directory in /usr/share and type in (www.address.com/sharedir) then it will serve out of the /usr/share directory. I have looked in the apache config file and default site config file and do not see this association. I do not want this behavior and am concerned that this is the default behavior out of the box.
Can anyone guide me to another areas where this behavior may be controlled/managed.
Thanks for any assistance.
Open your
/etc/apache2/sites-available/default
file and replace
/var/www
to
/path/to/folder/you/wish
save and it will be better to restart apache by
service apache2 restart
Now put website contents to the new location /path/to/folder/you/wish.
Once you changed the Document root of the of the site as mentioned above, Then no files will be fetched from any other location. Hopes this will help you. :)
[SOLVED] After a bunch more digging around I discovered that the user that originally set up this server erroneously put .conf files in the 'conf.d' directory and 'mods-enabled' directory that were routing traffic to the other directories. Sorry to anyone that noodled on this one.
I'm running XDebug on Linux CentOS. I want to profile pages on a web app built with CodeIgniter, served by Apache.
XDebug is enabled in php.ini with the following settings:
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /tmp/xdebug
Everything works fine when I trigger php scripts from the command line, and XDebug profile logs are written to /tmp/xdebug, as expected. When I load a url from the web app through the browser, XDebug does not create any profile log files.
Has anyone gotten XDebug to work with Codeigniter? From what I can tell, I should not have to trigger XDebug profiling via GET in the url because profiler_enable is turned on for all php scripts, although I've tried this and it doesn't seem to work either.
Apache needed to have write permissions on the /tmp/xdebug folder.
sudo chown -R apache:apache /tmp/xdebug
XDebug can profile Codeigniter page loads from a browser now.
Thanks #J. Bruni.
It seems to me that the issue is not related to CodeIgniter... It seems you may have multiple php.ini files...
In my Ubuntu installation, I have several sub-directories inside /etc/php5 directory: cgi, cli, fpm, etc. Each one of these has a php.ini file inside it, which is specific to a single "mode".
In other words: PHP may have several different php.ini files... one for CLI (command-line), other for CGI, and so on...
Maybe the xdebug configuration lines you pasted above are not in the php.ini file used when you access PHP scripts from the browser. Maybe you added these lines to /etc/php5/cli/php.ini instead of /etc/php5/cgi/php.ini (or another... in my setup, it is /etc/php5/fpm/php.ini, because I use php-fpm)