When I am editing my website, I saw the following messages on dashboard and website. After reinstalled the plugin, the error message on website was gone but it still showed on the dashboard (see the 1st screenshot). The other error messages were shown on editing pages, please find the 2nd screenshot). Could you please let me know how to fix them? Thank you.
Deprecated : Creation of dynamic property Kadence_Starter_Templates\Logger::$min_level is deprecated in /home/vol15_2/epizy.com/epiz_32829871/htdocs/wp-content/plugins/kadence-starter-templates/class-kadence-starter-templates.php on line 2650
Deprecated : str_replace(): Passing null to parameter #1 ($search) of type array|string is deprecated in /home/vol15_2/epizy.com/epiz_32829871/htdocs/wp-content/mu-plugins/endurance-page-cache.php on line 862 Warning : is_dir(): open_basedir restriction in effect. File(/22/) is not within the allowed path(s): (/php_sessions:/tmp:…:/var/www/errors:/usr/share/pear:/home/vol15_2/epizy.com/epiz_32829871/htdocs) in /home/vol15_2/epizy.com/epiz_32829871/htdocs/wp-content/mu-plugins/endurance-page-cache.php on line 877
This seems like an error related to PHP 8+. InfinityFree has been upgrading the servers to use PHP 8 instead of 7.4. The problem is most likely that your plugin or theme is using older PHP code and the new version of PHP is warning you about some older coding method that is now deprecated. The warning is telling you that there is a property you are trying to set which isn’t declared in the class or any of its parents.
It’s a deprecation warning. Those are usually safe to ignore, especially when using software you didn’t create yourself. A deprecation warning simply tells you that the code is still working now, but will break in future PHP versions. But that’s up to the developers of the software to worry about, not you.
If you disable WP_DEBUG and display_errors on your site (which is best practice during normal operation, only enable it temporarily while debugging), those messages will disappear with no impact to your site.
This seems like the Endurance Page Cache plugin is trying to write cache to a location where our server doesn’t allow you to.
The “Endurance” family of plugins are injected into website by the hosting from the Endurance group, such as HostGator. Those plugins are designed to interact with specific functionality on their hosting platform. Of course, other hosting providers don’t have those specific integrations, so those plugins should not be used on any other hosting.
So please remove the Endurance Page Cache plugin. If you want caching on your site, please switch to a generic caching plugin such as WP Super Cache or W3 Total Cache instead. I recommend against using LiteSpeed Cache: just like with the Endurance cache, it’s designed to interact with specific server software that we don’t have.
Do you mean I should change line 88 as below and remove line 91 and 92 code?
define( ‘WP_DEBUG’, false);
As per your suggestion, I deleted the endurance-page-cache.php file. The related message was gone. May I know if I can also add the following codes in mu-plugin folder to enable “automatic updates”?
The other question is where to get details of ‘DB_NAME’ / ‘DB_USER’ / ‘DB_PASSWORD’ / ‘DB_HOST’ in wp-config.php file? As I have migrated the website, the old wp-config.php file has been removed.
The define function is supposed to configure a constant, meaning something that’s set once and never changed. If you set it to true first, and then try changing it to false, it likely ignores it because the WP_DEBUG constant is already set.
You can enable it if you want. However, please note that there is a chance that automatic updates can break your site. To ensure your site keeps running, you may want to disable automatic updates, and only trigger updates by hand. That way, you can make backups before if you want, or at least check whether the update was successful and fix it if not, in case something goes wrong.
Please make sure to always keep your wp-config.php file. It can be reconstructed, but that can be quite difficult.
Those are the configuration values telling WordPress where it’s database is and how to access it. The DB_USER, DB_PASSWORD and DB_HOST can be found in the client area in the MySQL Databases menu of your account. The DB_NAME is the name of the database that has your WordPress data. The list of databases can also be seen in the MySQL Databases menu.
On second check, you seemed to have defined WP_DEBUG twice, which may cause issues in the error log. It might not affect the functionality of the site but it’s always best to only keep one, and you need one with false.
The part should look like this after editing:
90: /* Add any custom values between this line and the "stop editing" line. */
91: // Disable WP_DEBUG mode
92: define( 'WP_DEBUG', false );
93: /*That's all, stop editing! Happy publishing. */
For this part, mu-plugins are generally for vendor-specific plugins that aren’t likely to be updated using the WordPress update routine. You may want to go with normal plugins if you intend to have users receive updates via wordpress.org. Otherwise, simply replace the files on mu-plugin/.
You can get this info from the client area, if you lose this info, just create a new set of credentials that connect to the same database. As long as you have all the data in that previous database and uploaded files, you’re good to set up again without losing data.
The green code enables debugging, while the yellow one disables it. You should consider keeping the yellow one and remove the green one if you want to disable debugging; either way, that change won’t break your website.