Wordpress: An error occurred in the upload - wordpress

After updating to WordPress 3.5, I started getting the following error when uploading files using the Add Media button as a non-admin user:
Error: An error occurred in the upload. Please try again later.
The image seems to finish uploading, but right at the end this error message appears.
This doesn't happen for the administrator, only the other roles. I've even tried giving the other role full admin capabilities, but the error still appears.
Is this a bug? Or am I missing something?

After much trial and error, I finally found a solution that worked for me.
First, I found the following role capabilities to be required to upload files for custom user roles:
$capabilites = array(
'read' => true,
'upload_files' => true,
'edit_published_pages' => true,
'edit_others_pages' => true
);
I'm not sure why these are specifically required, but the error kept occurring without them.
Second, I had to update a function I was using to prevent non-admin users from accessing the Dashboard:
function redirect_nonadmin_fromdash(){
if($_SERVER['PHP_SELF'] == '/wp-admin/async-upload.php'){
/* allow users to upload files */
return true;
} else if(get_user_role() != 'administrator'){
/* custom function get_user_role() checks user role,
requires administrator, else redirects */
wp_safe_redirect(home_url());
exit;
}
}
add_action( 'login_form_login', 'redirect_nonadmin_fromdash' );
add_action( 'admin_init', 'redirect_nonadmin_fromdash', 1 );
Previously, I was checking for the media-upload.php, but the new media uploader uses async-upload.php.
So, essentially, this allows non-admin users to use the new media uploader from the front-end without allowing them access to the Dashboard.
It also restricts their access to the Media Library, which was also important to me.

This could be caused by a couple of different factors, what this usually suggests is:
File is to large
Refeer to this thread on how to up the maximum allowed filesize.
Not enough diskspace
Check if your servers harddrive is full.
Insufficient write permissions
Make sure that PHP and your webserver has write permissions to the wp-uploads folder.

I just had this error after updating PHP to 5.3. The problem on me was short_open_tag.
It was off by default. I enabled it and all is OK now.

I resolve my problem with,
sudo apt-get update
sudo apt-get install php5-gd
this message i get in firebug inspect in moment of upload.
GD Library Error: imagecreatetruecolor does not exist - please contact your webhost and ask them to install the GD libraryGD Library Error: imagecreatetruecolor does not exist - please contact your webhost and ask them to install the GD library{"success":true,"data":{"id":17,"title":"yoshi","filename":"yoshi1.jpg"
so i get this in firebug in moment of upload.

Please see this link for more details - it helped me https://sebastian.expert/fix-wordpress-an-error-occurred-in-the-upload-please-try-again-later/
Basically what it says is to use Developer tools in Chrome or Firefox to see the response from async_upload.php file after uploading files (when error message appears). It returns error details in JSON format. Having details it will be easier and a lot faster to resolve the problem.

Related

Drupal - Disable SAML login in local instance

I am very new to Drupal. I have done the local setup and the front end is working fine. Now I need to login to the admin interface. Seems like there is a SAML configuration and when I try to access the /user/login page it is showing the following error :
The website encountered an unexpected error. Please try again later.
I can see there is one simplesaml folder in the codebase and I think this is handling the SAML login. Now in the local setup, I don't need to use SSO, but not sure how to disable this extension. I have checked in the core.extension.yml, but the fllowing extensions set to 0 there and hence I think this is not activated.
basic_auth: 0
externalauth: 0
simplesamlphp_auth: 0
Also in my local configuration settings.local.php, it is set as false:
$config['simplesamlphp_auth.settings']['activate'] = FALSE;
It will be very much helpful if somebody can guide me in the right direction. I have access to the database, but not sure where I need to make changes. This might be a simple thing, but I am blocked here.
The Error I am seeing the logs is like this :
Uncaught PHP Exception SimpleSAML\Error\Exception: "Could not find the metadata of an IdP with entity ID 'localhost:default:entityId'" at /vendor/simplesamlphp/simplesamlphp/modules/saml/lib/Auth/Source/SP.php line 317
You can login to Drupal using a console command.
Open a terminal, navigate to the project folder like
cd ~/project/my-project/web/
Then run
drush uli
the output will be a one time login link.

Wordpress plugin: Parse error: syntax error, unexpected 'else' (T_ELSE), expecting function (T_FUNCTION)

I messed around in the code of a plugin for woocommerce (paypal for woocommerce). After that I couldnt open the website or reach the backend to deactivate the plugin. I managed to restore my page, I had a back up. I can open the website and use the backend, except plugins. When I click plugins or move to specific pages on my website I get this error:
Parse error: syntax error, unexpected 'else' (T_ELSE), expecting function (T_FUNCTION) in /home/arabst8/public_html/abaya-store/wp-content/plugins/paypal-for-woocommerce/classes/wc-gateway-paypal-express-angelleye.php on line 997
This is line 977 of that file:
if( $this->skip_final_review == 'yes' && ( get_option('woocommerce_enable_guest_checkout') === "yes" && apply_filters('woocommerce_enable_guest_checkout', get_option('woocommerce_enable_guest_checkout')) == "yes" || is_user_logged_in() )) {
I am suprised that a full restore from a backup didnt fix it? I also deleted the plugin via FTP and STILL received the message, which was even stranger.
Okay, its fixed now but maybe it would be good if someone would still explain the issue for other people who get this error. Because my fix was sort of random:
I run a chaching plug in (W3 total cache). I tried to purge all cache earlier and it didnt do much. I didnt it again. Right after that:
I managed to go directly to the "Editor" function of plugins, I choose the file in question and without changing anything in the code I clicked "update".
That did it. Because I didnt test after the Purge I dont know if it was that or the second update. But it works again now.

call wp_enqueue_media on wordpress page

I am using a custom theme that when I access http://ec2-54-255-182-157.ap-southeast-1.compute.amazonaws.com/shop/ , it gives the error that
upload-media.js?ver=1:3 Uncaught TypeError: Cannot read property 'editor' of undefined
it happends at the code _orig_send_attachment = wp.media.editor.send.attachment;
some google search (like here https://codestag.com/how-to-use-wordpress-3-5-media-uploader-in-theme-options/
) suggests that "Above code snippet works on post edit page only, to make it work elsewhere you need to use wp_enqueue_media(); in your theme. Thanks to daviedR for correcting me on this."
Any idea how to do call wp_enqueue_media() on this page?
it turns out to be caused by mbstring is not enabled. After run yum install php56-mbstring and restart httpd service, it works good now.

Drupal - White Screen of Death after updates (and login page returning 403 error)

I have just updated a site that is using Drupal and have now experienced the horrible WSOD.
I have searched through Google looking for any sort of solution/error log to help me find and fix the issue but nothing has worked. I have tried adding in the 'display errors' code in the index.php file and looked at the error_log file in the public directory and nothing.
I can not login to the admin page and check any modules as the login page for this is returning a 403 error.
Any suggestions?
Please go to Apache Error log. You will exact error messages there.
The log file's location is different for different OS and versions.
e.g httpd/log/error.log
Maybe your Drupal registry is broken.
Fix this using the registry_rebuild script (this is no module!)
There are times in Drupal 7 when the registry gets hopelessly hosed and you need to rebuild the registry (a list of PHP classes and the files they go with). Sometimes, though, you can't do this regular cache-clear activity because some class is required when the system is trying to bootstrap.
You might get something like:
PHP Fatal error: Class 'EntityAPIControllerExportable' not found in ...sites/all/modules/rules/includes/rules.core.inc on line 11
If this happens when you're trying to run update.php, and happens when you're trying to clear your cache, well, you have some trouble. That's what Registry Rebuild is for.
It also may happen that you've moved some module that Drupal requires to bootstrap, and you get a horrible error. Registry Rebuild will also rebuild the system table to get the modules in the right place so you can bootstrap.
You will need PHP-CLI or drush to run this.
https://drupal.org/project/registry_rebuild

How can I check Drupal log files?

How can I check Drupal log files?
I'm using Ubuntu 10.10 + Apache2 + PHP 5.33 + MySQL and Drupal 7.
To view entries in Drupal's own internal log system (the watchdog database table), go to http://example.com/admin/reports/dblog. These can include Drupal-specific errors as well as general PHP or MySQL errors that have been thrown.
Use the watchdog() function to add an entry to this log from your own custom module.
When Drupal bootstraps it uses the PHP function set_error_handler() to set its own error handler for PHP errors. Therefore, whenever a PHP error occurs within Drupal it will be logged through the watchdog() call at admin/reports/dblog. If you look for PHP fatal errors, for example, in /var/log/apache/error.log and don't see them, this is why. Other errors, e.g. Apache errors, should still be logged in /var/log, or wherever you have it configured to log to.
If you love the command line, you can also do this using drush with the watchdog show command:
drush ws
More information about this command available here:
https://drushcommands.com/drush-7x/watchdog/watchdog-show/
Make sure drush is installed (you may also need to make sure the dblog module is enabled) and use:
drush watchdog-show --tail
Available in drush v8 and below.
This will give you a live look at the logs from your console.
We came across many situation where we need to check error and error logs to figure out issue we are facing we can check by possibly following method:
1.) On blank screen
Some time we got nothing but blank screen instead of our site or message written The website encountered an unexpected error. Please try again later , so we can Print Errors to the Screen
by adding
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
in index.php at top.;
2.) We should enable optional core module for Database Logging at /admin/build/modules, and then we can check logs your_domain_name/admin/reports/dblog
3.) We can use drush command also to check logs
drush watchdog-show it will show recent ten message
or if we want to continue showing logs with more information we can user
drush watchdog-show --tail --full.
4.) Also we can enable core Syslog module this module logs events of operating system of any web server.
We can use drush command also to check logs
drush watchdog-show it will show recent 10 messages.
or if we want to continue showing logs with more information we can user
drush watchdog-show --tail --full.
MAMP/logs/php_error.log
Above all given option does not work go to the MAMP/logs/ check all type of log-like.
mysql_error.log
nginx_error.log
apache_error.log
For drupal 9, you can access to your logs with drush , here some commands:
watchdog:delete (wd-del, wd-delete, wd) Delete watchdog log records.
watchdog:list (wd-list) Interactively filter the watchdog message listing.
watchdog:show (wd-show, ws) Show watchdog messages.
watchdog:show-one (wd-one) Show one log record by ID.
watchdog:tail (wd-tail, wt) Tail watchdog messages.
One more thing if your are not fan with commands, please in the Administrative menu, go to Reports > Recent log messages. On this page is a list of recent log messages which you can filter by type and severity.
but if your are professional you can configure ELK that's will give you all
In Drupal, you can check the log files through the Drupal admin interface or by accessing the server files directly. Here are the steps for each method:
Through the Drupal admin interface:
Log in to your Drupal site as an administrator.
Go to Reports > Recent log messages.
This will show you a list of recent log entries, filtered by severity level and type.
By accessing server files:
Connect to your server via FTP or SFTP.
Locate your Drupal installation directory.
Look for the "logs" directory or server level /var/log.
Open the log files you want to view.
Note: The location of the log files may vary depending on your Drupal installation and server configuration. You may need to consult your hosting provider or server administrator for help finding the logs.

Resources