WordPress Errors due to PHP incompatibility

Our business website uses WordPress. We have a theme bought from the market place and Elementor for page designs. The whole setup costed us something below 200$ & we are happy with the way the site delivers all our needs (not forgetting dozens of plugins that we use for basic features)

Recently we noticed “Elementor” throwing few errors while the pages were getting loaded. Errors were like “Deprecated: _register_skins is deprecated since version“. A quick Google search landed us on this discussion & rolled back Elementor to a previous version as suggested by one of the users and expected no further issues.

We were wrong. We started getting serious issues related to Jetpack, a plugin that is provided by “Automatic”, WordPress’s own repository. Our pages started showing some weird messages while loading and we were completely denied WordPress Admin page access. Our hosting company renamed the plugin folder & we were able to log on and disable Jetpack plugin, which was not recommended by many.

Much of the Jetpack related errors were like get_name(), get_title(),get_description(),get_long_description(),get_features(),get_pricing_for_ui(),get_manage_url() should not be abstract in & Warning: Cannot modify header information…

Jetpack error(s)

Then I remembered about a PHP related warning I have noticed during the last admin panel visit. WordPress was recommending PHP upgrade as they were in the process of stop supporting PHP 5.x versions. So I approached our hosting & asked them to upgrade the available PHP options for us. Once after they installed the latest available versions, we switched to PHP 7.4 (7.3 is deprecated already) from 5.6 . Proceeded with enabling Jetpack and upgraded Elementor to latest.

Everything started working as expected. So if you started facing Elementor or Jetpack related errors all of a sudden, before breaking your head anywhere else, check the version of PHP & give a try by upgrading it to one of the not deprecated versions.

Linux HugePages for Oracle

Few weeks back one DBA told me there is no need to setup HugePages as we are not using 40+GB SGA & we had it enabled from the initial days of 11g migration from 10g (10.2.0.3). Well, here is how you can setup HugePages for your Oracle database instance.

A brief explanation that might help you to decide whether you should enable HugePages or not is quoted from Tim Hall’s article below.

“For large SGA sizes, HugePages can give substantial benefits in virtual memory management. Without HugePages, the memory of the SGA is divided into 4K pages, which have to be managed by the Linux kernel. Using HugePages, the page size is increased to 2MB (configurable to 1G if supported by the hardware), thereby reducing the total number of pages to be managed by the kernel and therefore reducing the amount of memory required to hold the page table in memory. In addition to these changes, the memory associated with HugePages can not be swapped out, which forces the SGA to stay memory resident. The savings in memory and the effort of page management make HugePages pretty much mandatory for Oracle 11g systems running on x86-64 architectures.

Recently I had a short Twitter exchange with Tim Hall about the subject & He mentioned that he always enables it.

Please refer the article from below link, it is by Tim Hall, a geek in this field and the owner of https://oracle-base.com

https://oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64

Exercises explained in this article is applicable to 19c also (verified as working). Please make sure that your version of Oracle database supports these settings before attempting. Please do not copy this to PRODUCTION environments without enough testing.