In wordpress admin panel, under Appearance - Menus item was working properly. Suddenly this menu item stopped working. I am getting the below error in admin panel
Fatal error: Maximum execution time of 60 seconds exceeded in /public_html/wp-content/plugins/sitepress-multilingual-cms/classes/query-filtering/wpml-query-filter.class.php on line 248
Warning: Invalid argument supplied for foreach() in /public_html/wp-includes/class-wp-hook.php on line 277
Warning: Invalid argument supplied for foreach() in /public_html/wp-includes/class-wp-hook.php on line 277
Warning: Invalid argument supplied for foreach() in /public_html/wp-includes/class-wp-hook.php on line 277
Can anyone please help to fix this issue?
That seems to be a WPML problem.
Set the max_execution_time to 300 (which is 5 minutes) to see if it works.
You can set it in your .htaccess file with php_value max_execution_time 300.
Or you could do it with PHP: ini_set('max_execution_time', 300);
ini_set('max_execution_time', 300);
Place this at the top of your PHP script and let your script loose!
this link
and set .htaccess file : php_value max_execution_time 300
Warning: Cannot modify header information - headers already sent by (output started at /home/tomproje/site/sgaotw.com/wp-config.php:1) in /home/tomproje/site/sgaotw.com/wp-admin/includes/misc.php on line 1115
what is the problem online 1115 ? I try to solve this problem , i read every topic about this problem , but not found an answer .
line 1115
It sounds like there could be some blank space in a PHP file somewhere. Try checking your wp-config.php file and seeing if there's a character before the opening <?php tag.
Trying to import Divi layouts (.json files)
Getting this error:
This file cannot be imported. It may be caused by file_uploads being
disabled in your php.ini. It may also be caused by post_max_size or/and
upload_max_filesize being smaller than file selected. Please increase
it or transfer more substantial data at the time.
This is not the case, however as I don't have a limit on either and I can upload anywhere else within my WP installation.
Does anyone have any idea what else would cause this error?
My response pertains to Divi Theme Version 3.0.46
I had the same problem, and what follows is how I fixed it.
In my case the error is being generated from the Divi Builder portability.js file, line 464:
var fileSize = Math.ceil( ( data.file.size / ( 1024 * 1024 ) ).toFixed( 2 ) ),
formData = new FormData();
// Max size set on server is exceeded.
if ( fileSize >= $this.postMaxSize || fileSize >= $this.uploadMaxSize ) {
etCore.modalContent( '<p>' + $this.text.maxSizeExceeded + '</p>', false, true, '#' + $this.instance( '.ui-tabs-panel:visible' ).attr( 'id' )\
);
$this.enableActions();
return;
}
The thing to note here is, this script is rounding the max upload sizes to whole numbers of MB.
So my max file size for this site was 2MB, and my file is 1,495,679 bytes, which the script turned into:
if 2>=2 {
// throw an error
}
So it seems, the solution is to make both your php upload max size and max post size at least 1MB greater than the file you are trying to upload.
The Elegant Themes people have a lengthy post on this:
https://www.elegantthemes.com/blog/tips-tricks/is-the-wordpress-upload-limit-giving-you-trouble-heres-how-to-change-it
This is as simple as setting this in my php.ini.
; TO have a 31.4MB file upload into Divi, these must be at least 32MB.
post_max_size = 32M
upload_max_filesize = 32M
The final thing I want to say about this as since this error is generated by javascript in the browser, you must:
change your php.ini
restart your webserver [at least I needed to w/ Apache]
refresh the page, as the limits are cached in the browser, not the result of any sort of ajax call, etc.
I had the same issue.I googled and found the solution below.(Apology for not having a proper explanation!)
Solution:
Create a new file php.ini with the following text & save in website's root directory and it's done.
file_uploads = On
upload_max_filesize = 100M
post_max_size = 100M
Error:
Warning: Cannot modify header information - headers already sent by
(output started at /home/ya3mblog/public_html/wp-login.php:59) in
/home/ya3mblog/public_html/wp-includes/pluggable.php on line 866
website: ipublisharticles.com Error is at:
ipublisharticles.com/wp-login.php?action=register
It's preventing user registration using the proper method.
Add this code in wp-config.php on the first line:
ob_start();
error_reporting(0);
See How_do_I_solve_the_Headers_already_sent_warning_problem? > FAQ Troubleshooting « WordPress Codex
(This error) is usually because there are spaces, new lines, or other
stuff before an opening <?php tag or after a closing ?> tag,
typically in wp-config.php.
Open the file with a plain text editor (like Notepad or BBEdit) and clear out the white space. Check that the very first characters are <?php
and the very last characters are either NOT a PHP closing tag, or a closing tag ?> with no blank lines or spaces after it. (FYI, a PHP file can run fine without the closing ?> tag.)
When saving, be sure the file encoding is not UTF-8 BOM but plain UTF-8 or any without the BOM suffix.
And:
This could be true about some other file too, so please check the
error message, as it will list the specific file name where the error
occurred. Replacing the faulty file with one from your most recent
backup or one from a fresh WordPress download is your best bet.
If the error message states: Warning: Cannot modify header information
- headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42,
then the problem is at line #34 of wp-config.php, not line #42 of
wp-login.php. In this scenario, line #42 of wp-login.php is the
victim. It is being affected by the excess whitespace at line #34 of
wp-config.php.
If the error message states: Warning: Cannot modify header information
- headers already sent by (output started at /path/wp-admin/admin-header.php:8) in /path/wp-admin/post.php on line
569, then the problem is at line #8 of admin-header.php, not line #569
of post.php. In this scenario, line #569 of post.php is the victim. It
is being affected by the excess whitespace at line #8 of
admin-header.php.
remove the excess blankspace /home/ya3mblog/public_html/wp-login.php in line 59.
In my case happened because from the Wordpress Rest API in the functions I was ending the job by doing
echo json_encode($result);
instead of the simple:
return $result;
Changing that.. worked!
I have made a function that finds all the URLs within an html file and repeats the same process for each html content linked to the discovered URLs. The function is recursive and can go on endlessly. However, I have put a limit on the recursion by setting a global variable which causes the recursion to stop after 100 recursions.
However, php returns this error:
Fatal error: Maximum function nesting level of '100' reached,
aborting! in
D:\wamp\www\crawler1\simplehtmldom_1_5\simple_html_dom.php on line
1355
I found a solution here: Increasing nesting function calls limit but this is not working in my case.
I am quoting one of the answers from the link mentioned above. Please do consider it.
"Do you have Zend, IonCube, or xDebug installed? If so, that is probably where you are getting this error from.
I ran into this a few years ago, and it ended up being Zend putting that limit there, not PHP. Of course removing it will let >you go past the 100 iterations, but you will eventually hit the memory limits."
Is there a way to increase the maximum function nesting level in PHP
Increase the value of xdebug.max_nesting_level in your php.ini
A simple solution solved my problem. I just commented this line:
zend_extension = "d:/wamp/bin/php/php5.3.8/zend_ext/php_xdebug-2.1.2-5.3-vc9.dll
in my php.ini file. This extension was limiting the stack to 100 so I disabled it. The recursive function is now working as anticipated.
Another solution is to add xdebug.max_nesting_level = 200 in your php.ini
Rather than going for a recursive function calls, work with a queue model to flatten the structure.
$queue = array('http://example.com/first/url');
while (count($queue)) {
$url = array_shift($queue);
$queue = array_merge($queue, find_urls($url));
}
function find_urls($url)
{
$urls = array();
// Some logic filling the variable
return $urls;
}
There are different ways to handle it. You can keep track of more information if you need some insight about the origin or paths traversed. There are also distributed queues that can work off a similar model.
Rather than disabling the xdebug, you can set the higher limit like
xdebug.max_nesting_level=500
It's also possible to fix this directly in php, for example in the config file of your project.
ini_set('xdebug.max_nesting_level', 200);
Go into your php.ini configuration file and change the following line:
xdebug.max_nesting_level=100
to something like:
xdebug.max_nesting_level=200
on Ubuntu using PHP 5.59 :
got to `:
/etc/php5/cli/conf.d
and find your xdebug.ini in that dir, in my case is 20-xdebug.ini
and add this line `
xdebug.max_nesting_level = 200
or this
xdebug.max_nesting_level = -1
set it to -1 and you dont have to worry change the value of the nesting level.
`
probably happened because of xdebug.
Try commenting the following line in your "php.ini" and restart your server to reload PHP.
";xdebug.max_nesting_level"
Try looking in /etc/php5/conf.d/ to see if there is a file called xdebug.ini
max_nesting_level is 100 by default
If it is not set in that file add:
xdebug.max_nesting_level=300
to the end of the list so it looks like this
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=/home/drupalpro/websites/logs/profiler
xdebug.max_nesting_level=300
you can then use #Andrey's test before and after making this change to see if worked.
php -r 'function foo() { static $x = 1; echo "foo ", $x++, "\n"; foo(); } foo();'
php.ini:
xdebug.max_nesting_level = -1
I'm not entirely sure if the value will ever overflow and reach -1, but it'll either never reach -1, or it'll set the max_nesting_level pretty high.
You could convert your recursive code into an iterative code, which simulates the recursion. This means that you have to push the current status (url, document, position in document etc.) into an array, when you reach a link, and pop it out of the array, when this link has finished.
Check recursion from command line:
php -r 'function foo() { static $x = 1; echo "foo ", $x++, "\n"; foo(); } foo();'
if result > 100 THEN check memory limit;
You could try to wiggle down the nesting by implementing parallel workers (like in cluster computing) instead of increasing the number of nesting function calls.
For example: you define a limited number of slots (eg. 100) and monitor the number of "workers" assigned to each/some of them. If any slots become free, you put the waiting workers "in them".
<?php
ini_set('xdebug.max_nesting_level', 9999);
... your code ...
P.S. Change 9999 to any number you want.
Stumbled upon this bug as well during development.
However, in my case it was caused by an underlying loop of functions calling eachother - as a result of continuous iterations during development.
For future reference by search engines - the exact error my logs provided me with was:
Exception: Maximum function nesting level of '256' reached, aborting!
If, like in my case, the given answers do not solve your problem, make sure you're not accidentally doing something along the lines of the following simplified situation:
function foo(){
// Do something
bar();
}
function bar(){
// Do something else
foo();
}
In this case, even if you set ini_set('xdebug.max_nesting_level', 9999); it will still print out the same error message in your logs.
If you're using Laravel, do
composer update
This should be work.
In your case it's definitely the crawler instance is having more Xdebug limit to trace error and debug info.
But, in other cases also errors like on PHP or core files like CodeIgniter libraries will create such a case and if you even increase the x-debug level setting it would not vanish.
So, look into your code carefully :) .
Here was the issue in my case.
I had a service class which is library in CodeIgniter. Having a function inside like this.
class PaymentService {
private $CI;
public function __construct() {
$this->CI =& get_instance();
}
public function process(){
//lots of Ci referencing here...
}
My controller as follow:
$this->load->library('PaymentService');
$this->process_(); // see I got this wrong instead it shoud be like
Function call on last line was wrong because of the typo, instead it should have been like below:
$this->Payment_service->process(); //the library class name
Then I was keeping getting the exceed error message. But I disabled XDebug but non helped. Any way please check you class name or your code for proper function calling.
I had a error when i was installing many plugins So the error 100 showed including the location of the last plugin that i installed C:\wamp\www\mysite\wp-content\plugins\"..." so i deleted this plugin folder on the C: drive then everything was back to normal.I think i have to limit the amount of plug-in i install or have activated .good luck i hope it helps
I had this issue with WordPress on cloud9. It turns out it was the W3 Caching plugin. I disabled the plugin and it worked fine.
Another solution if you are running php script in CLI(cmd)
The php.ini file that needs edit is different in this case. In my WAMP installation the php.ini file that is loaded in command line is:
\wamp\bin\php\php5.5.12\php.ini
instead of \wamp\bin\apache\apache2.4.9\bin\php.ini which loads when php is run from browser
You can also modify the {debug} function in modifier.debug_print_var.php, in order to limit its recursion into objects.
Around line 45, before :
$results .= '<br>' . str_repeat(' ', $depth * 2)
. '<b> ->' . strtr($curr_key, $_replace) . '</b> = '
. smarty_modifier_debug_print_var($curr_val, ++$depth, $length);
After :
$max_depth = 10;
$results .= '<br>' . str_repeat(' ', $depth * 2)
. '<b> ->' . strtr($curr_key, $_replace) . '</b> = '
. ($depth > $max_depth ? 'Max recursion depth:'.(++$depth) : smarty_modifier_debug_print_var($curr_val, ++$depth, $length));
This way, Xdebug will still behave normally: limit recursion depth in var_dump and so on.
As this is a smarty problem, not a Xdebug one!
I had the same problem and I resolved it like this:
Open MySQL my.ini file
In [mysqld] section, add the following line: innodb_force_recovery =
1
Save the file and try starting MySQL
Remove that line which you just added and Save