Wordpress PHP Fatal Error with Openshift - php

When I try to access the plugins or themes section of my wordpress site from the admin panel I am presented with a blank screen. When I run the logs I get the following error:
Navigating to wp-admin/plugins.php:
PHP Fatal error: Call to undefined function wp_json_encode() in /var/lib/openshift/{userID}/app-root/data/current/wp-includes/update.php on line 277
Navigating to wp-admin/themes.php:
PHP Fatal error: Call to undefined function wp_json_encode() in /var/lib/openshift/{userID}/app-root/data/current/wp-includes/update.php on line 440
Solutions online indicated that I should re-add the function, or re-install Wordpress. Without access to the core files, I downloaded a local repository of the application (but noticed it did not contain any of the plugins or themes I had uploaded via the admin interface).
I extracted a plugin and theme (placing them in the respective directories) then pushed the changes to production in the hopes that it would extract and re-install an updated version of wordpress. I then restarted the app.
The error still persists and I can not validate if the plugin or theme I uploaded were installed. Is there a way to refresh or reinstall a wordpress instance on Openshift?
I'm wondering how I can fix this issue without creating a new gear and migrating my data via the database. Note: Front end is working fine.
Version of Wordpress: 4.1.1

I ended up connecting to the app via SFTP and modified the file the following directly
/var/lib/openshift/{userID}/app-root/data/current/wp-includes/functions.php
and added the following function:
function wp_json_encode( $data, $options = 0, $depth = 512 ) {
/*
* json_encode() has had extra params added over the years.
* $options was added in 5.3, and $depth in 5.5.
* We need to make sure we call it with the correct arguments.
*/
if ( version_compare( PHP_VERSION, '5.5', '>=' ) ) {
$args = array( $data, $options, $depth );
} elseif ( version_compare( PHP_VERSION, '5.3', '>=' ) ) {
$args = array( $data, $options );
} else {
$args = array( $data );
}
$json = call_user_func_array( 'json_encode', $args );
// If json_encode() was successful, no need to do more sanity checking.
// ... unless we're in an old version of PHP, and json_encode() returned
// a string containing 'null'. Then we need to do more sanity checking.
if ( false !== $json && ( version_compare( PHP_VERSION, '5.5', '>=' ) || false === strpos( $json, 'null' ) ) ) {
return $json;
}
try {
$args[0] = _wp_json_sanity_check( $data, $depth );
} catch ( Exception $e ) {
return false;
}
return call_user_func_array( 'json_encode', $args );
}
Ref: https://wordpress.org/support/topic/fatal-error-call-to-undefined-function-wp_json_encode-in

Related

Error in WordPress with plugin reactpress

I'm using WordPress version 5.7.2 and when I upgrade it to php version 7.4.19 I get these errors:
Failed opening 'default' for inclusion (include_path='.:/usr/lib/php7.4') wp-includes/template-loader.php on line 106
Warning: include(default): failed to open stream: No such file or directory in /homepages/1/d229455270/htdocs/clickandbuilds/WordPress/DaseCMS/wp-includes/template-loader.php on line 106
This happens when I activate the plugin reactpress. This is the piece of code where the error occurs:
/**
* Filters the path of the current template before including it.
*
* #since 3.0.0
*
* #param string $template The path of the template to include.
*/
$template = apply_filters( 'template_include', $template );
if ( $template ) {
include $template; //Error in this line
} elseif ( current_user_can( 'switch_themes' ) ) {
$theme = wp_get_theme();
if ( $theme->errors() ) {
wp_die( $theme->errors() );
}
Why is this happening? How can I fix it? I see that is compatible with my WordPress version...
And with my php version...
Thank you in advance
Why is this happening?
Because there's a mistake in the Reactpress_Public::repr_change_page_template() method (see line 99 in wp-content/plugins/reactpress/public/class-reactpress-public.php) which is hooked onto template_include.
The author should check if the value of the _wp_page_template metadata (which stores the path of a custom page template) is not default (which is the default value) and only if so, then should the $template value be set to the metadata value.
And if one doesn't do that check, then we'd end up with include 'default' which then emits the error/warning in question ("Failed opening 'default' for inclusion").
How can I fix it?
Please contact the plugin support and ask them to fix the issue ASAP, but for the time being, you may just change the conditional here to: (* change the entire "if")
if (!empty($meta['_wp_page_template'][0]) && $meta['_wp_page_template'][0] != $template && // wrapped
'default' !== $meta['_wp_page_template'][0] // check if the value is NOT "default"
) {
$template = $meta['_wp_page_template'][0];
}
Yes, you shouldn't modify core plugin files; but this is a special case, because the plugin needs a fix, which hopefully will come in the plugin's next release.
Alternate solution without modifying the plugin files
.. is by overriding the template using the same hook:
// Add to the theme functions.php file:
add_filter( 'template_include', 'my_fix_template_include', 100 );
function my_fix_template_include( $template ) {
if ( 'default' === $template && is_page() ) { // * the plugin uses is_page()
$template = get_page_template();
}
return $template;
}

HTTP ERROR when trying to upload images from the wordpress

I am getting an HTTP ERROR when trying to upload images from the wordpress backend.
Tried a few suggestions of finding the php.ini file but unable to do so via SSH.
Also tried adding the below code
function ms_image_editor_default_to_gd( $editors ) {
$gd_editor = 'WP_Image_Editor_GD';
$editors = array_diff( $editors, array( $gd_editor ) );
array_unshift( $editors, $gd_editor );
return $editors;
}
add_filter( 'wp_image_editors', 'ms_image_editor_default_to_gd' );
Which did not help.
I am using an Ubuntu instance on Amazon Lightsail, Any help will be appreciated.

WP_Ajax_UnitTestCase does not throw WPAjaxDieStopException

Ok so I am testing my ajax callbacks for my wordpress plugin.
So I basically followed instructions here
https://codesymphony.co/wp-ajax-plugin-unit-testing/
Here is my ajax callback function
public function my_plugin_get_site_pages( $args = null ) {
//...... Processing $site_pages.....
$response = array(
'status' => 'success',
'site_pages' => $site_pages
);
#header( 'Content-Type: application/json; charset=' . get_option( 'blog_charset' ) );
echo wp_json_encode( $response );
wp_die();
}
Here is my test
class My_Plugin_Ajax_Test extends WP_Ajax_UnitTestCase {
private $_foo;
public function setup() {
//.....Initialize $_foo here...
}
public function test_foo() {
try {
$_POST[ 'args' ] = array( 'return_format' => 'raw' );
add_action( 'wp_ajax_my_plugin_get_site_pages' , array( $this->_foo , 'my_plugin_get_site_pages' ) );
//$this->setExpectedException( 'WPAjaxDieStopException' );
$this->_handleAjax( 'my_plugin_get_site_pages' );
} catch ( WPAjaxDieStopException $e ) {}
//$response = json_decode( $this->_last_response );
$response = $this->_last_response;
var_dump( $response );
}
}
Now here are the issues
It doesn't throw WPAjaxDieStopException exception like its suppose to
when I do this code $this->setExpectedException( 'WPAjaxDieStopException' );
it fails the test https://snag.gy/JSTqHV.jpg
It prints out that wp_die() has been triggered, so this code
$response = $this->_last_response;
var_dump( $response );
prints this
https://snag.gy/pKqfUk.jpg
Number 2 is an issue because you cannot do json_decode the string outputted coz its an invalid json string, so I can't continue with my test.
I'm just starting out with automated testing on wordpress plugins and I appreciate any help.
Note:
My ajax callback is working ok on my live plugin even if I use wp_die(), it just prints that weird 'wp_die called ...' string on my test.
My php version is 5.6.21 and my phpunit version is 4.8.26
Here are some additional info
So both 'WPAjaxDieStopException' and 'WPAjaxDieContinueException' are not thrown,
however what's interesting is when I do this
$this->_setRole( 'administrator' );
I get this error on the console
Trying to get property of non-object
/tmp/wordpress-tests-lib/includes/testcase-ajax.php:151
/vagrant/www/wordpress/wp-content/plugins/my-plugin/tests/test-file.php:30
But clearly I'm extending WP_Ajax_UnitTestCase and it has the _setRole method
https://core.trac.wordpress.org/browser/trunk/tests/phpunit/includes/testcase-ajax.php#L168
Also when I run phpunit I get this bunch of errors or warnings on the console
Installing...
Running as single site... To run multisite, use -c tests/phpunit/multisite.xml
WordPress database error Duplicate key name 'location_type_code' for query ALTER TABLE wptests_woocommerce_tax_rate_locations ADD KEY location_type_code (location_type(40),location_code(90)) made by PHPUnit_TextUI_Command::main, PHPUnit_TextUI_Command->run, PHPUnit_TextUI_Command->handleArguments, PHPUnit_TextUI_Command->handleBootstrap, PHPUnit_Util_Fileloader::checkAndLoad, PHPUnit_Util_Fileloader::load, include_once('/vagrant/www/wordpress/wp-content/plugins/my-plugin/tests/bootstrap.php'), require('/tmp/wordpress-tests-lib/includes/bootstrap.php'), require_once('wp-settings.php'), do_action('init'), call_user_func_array, WC_Install::check_version, WC_Install::install, WC_Install::create_tables, dbDelta
Also I am using vagrant and use http://vccw.cc/ for my dev env and also following this guide on adding tests for woocommerce extensions
https://github.com/Automattic/wc-extensions-code-test-guide
Hope all this additional info will help in finally solving this issue.
Been away for a while, been very busy, finally got some time to figure this out. It turns out it's a stupid mistake (facepalm).
Since we are using WP_Ajax_UnitTestCase which extends WP_UnitTestCase
Then when we use function setup in WP_Ajax_UnitTestCase then we need to call this parent::setup();
public function setup() {
parent::setup();
// your init codes here
}
I was not calling that on my existing code that's why the test is acting weird. Adding that solves all the weird issues and runs the test as expected and throws necessary exceptions.
WPAjaxDieStopException is thrown if ajax callback function does not yield any output.
WPAjaxDieContinueException is thrown if ajax callback yields any output.
Also make sure to use wp_die() instead of die() on your ajax callback, if you use the later, the test will halt.
I am planning to write and extensive guide to doing automated testing in WordPress plugins, I'll put the link to it here soon.
For now I hope this helps anyone.

PHP Parse Error in Wordpress project from a WPEngine backup

I've inherited a Wordpress project and I am trying to get it set up. I have zero experience in Wordpress and may as well say I have zero PHP experience. So far I've managed to get the environment set up on my local machine but I am stuck on a PHP parse error which I cannot find a solution for by googling. I'd like to at least get the existing project running on my machine.
When I open up my site locally I get redirected to $ROOT/wp-admin/install.php and I get this error in the apache error_log:
[Wed Oct 22 22:32:42 2014] [error] [client ::1] PHP Parse error: parse error in /path/to/project/wp-content/mu-plugins/wpengine-common/plugin.php on line 788
Line 788 is
public function disable_indiv_plugin_update_notices( $value ) {
and the surrounding code is
function wpengine_credits() {
if ( get_option( 'stylesheet' ) != 'twentyeleven' && get_option( 'template' ) != 'twentyeleven' )
return false;
if ( !defined('WPE_FOOTER_HTML') OR !WPE_FOOTER_HTML OR $this->already_emitted_powered_by == true )
return false;
//to prevent repeating
$this->already_emitted_powered_by = true; ?>
<div id="site-host">
WP Engine <?php printf( __( '%s.', 'wpengine' ), 'WordPress Hosting' ); ?>
</div>
<?php
}
public function disable_indiv_plugin_update_notices( $value ) {
$plugins_to_disable_notices_for = array();
$basename = '';
foreach ( $plugins_to_disable_notices_for as $plugin )
$basename = plugin_basename( $plugin );
if ( isset( $value->response[#$basename] ) )
unset( $value->response[$basename] );
return $value;
}
public function get_powered_by_html( $affiliate_code = null ) {
if ( ( ! defined('WPE_FOOTER_HTML') OR !WPE_FOOTER_HTML ) AND !$this->is_widget ) return "";
$this->already_emitted_powered_by = true;
if(WPE_FOOTER_HTML !== "") {
$html = WPE_FOOTER_HTML;
} else {
$html = $this->view('general/powered-by',array('affiliate_code'=>$affiliate_code),false);
}
return "<span class=\"wpengine-promo\">$html</span>";
}
I have a feeling it has to do with my PHP version. I am running PHP 5.4.30. Other solutions to similar problems suggested using
Any suggestions would be appreciated.
Delete the mu-plugins folder in you LOCAL environment... the error you are seeing is a special plugin run by WP Engine on their servers for internal use. It will, as you can see, fail if run outside the WP Engine environment.
Just make sure you don't delete the mu-plugins folder on the WP Engine server when you are putting the local environment back up to production!

MediaWiki upgrade (1.19.6 to 1.22.2) breaks - fetchContent() error

Just upgraded Mediawiki 1.19.6 to the most current, 1.22.2.
Used update.php, which worked just fine. The front page loads, as do SOME of the articles if you enter their exact URL. However, following any of the links produces:
Catchable fatal error: Argument 1 passed to
ContentHandler::getContentText() must implement interface Content,
boolean given, called in <wiki path>/includes/Article.php on line 389
and defined in <wiki path>/includes/content/ContentHandler.php on line
95.
I've looked up the call to getContentText() in Article.php, and it's in a function called fetchContent(), with a comment about it being crufty and a note that the ContentHandler method within is deprecated.
I can't figure out how to fix what's gone wrong, and web searches are only turning up bug reports that are marked fixed... any ideas? Thanks very much.
getContentText() is depreciated.
Use WikiPage::getContent()
https://doc.wikimedia.org/mediawiki-core/master/php/html/classArticle.html#affd3b52d2544cc334d7805ae9e5aba98
We had the same problem. Our ICT guy handled it by adapting the Article.php file placed in the includes directory of your mediawiki. Only 1 function was adapted (line 377 function function fetchContent()). I do not know the exact working principle but the MediaWiki returned to normal.
Also I believe you need to run the mediawiki update routine by visiting:
'HostAdress'/MediaWiki/mw-config/
Original function in Article.php:
function fetchContent() { #BC cruft!
ContentHandler::deprecated( __METHOD__, '1.21' );
if ( $this->mContentLoaded && $this->mContent ) {
return $this->mContent;
}
wfProfileIn( __METHOD__ );
$content = $this->fetchContentObject();
// #todo Get rid of mContent everywhere!
$this->mContent = ContentHandler::getContentText( $content );
ContentHandler::runLegacyHooks( 'ArticleAfterFetchContent', array( &$this, &$this->mContent ) );
wfProfileOut( __METHOD__ );
return $this->mContent;
}
New function in Article.php:
function fetchContent() { #BC cruft!
ContentHandler::deprecated( __METHOD__, '1.21' );
if ( $this->mContentLoaded && $this->mContent ) {
return $this->mContent;
}
wfProfileIn( __METHOD__ );
$content = $this->fetchContentObject();
if ( !$content ) {
wfProfileOut( __METHOD__ );
return false;
}
// #todo Get rid of mContent everywhere!
$this->mContent = ContentHandler::getContentText( $content );
ContentHandler::runLegacyHooks( 'ArticleAfterFetchContent', array( &$this, &$this->mContent ) );
wfProfileOut( __METHOD__ );
return $this->mContent;
}

Categories