My plugin not updating properly (issue with upgrader_process_complete) - php

I have users who have installed my plugin (we'll call it v6).
V6 version of my plugin does not register a handler for upgrader_process_complete.
In my new version, I have upgrader_process_complete registered to do some upgrades to my database table.
However, it seems that when the user upgrades from the Plugins page using the update now link, the handler of my new version is not invoked.
Could anyone shed some light on this issue?

The upgrader_process_complete hook is running in the current version while updating the plugin.
Let say that you are running plugin v 6.0.
And then you are just updated to 6.1 which contain upgrader_process_complete hook in this version.
The upgrader hook will not be called until next scenario.
Now you have running plugin v 6.1 which contain upgrader_process_complete hook since v 6.1.
And you are just updated to 6.2 which contain the code that write ABC.txt file.
The upgrader hook for 6.1 will be called, NOT 6.2. So, it means that the ABC.txt file will not be created.
If you are running plugin v 6.1 and want to run the newly updated code from 6.2 that just updated, you have to add something like transient to get notice that the update from new version of code is need.
And here is from my plugin. You can use as you need under MIT license.
<?php
class Upgrader
{
/**
* Display link or maybe redirect to manual update page.
*
* To understand more about new version of code, please read more on `updateProcessComplete()` method.
*
* #link https://codex.wordpress.org/Plugin_API/Action_Reference/admin_notices Reference.
*/
public function redirectToUpdatePlugin()
{
if (get_transient('myplugin_updated') && current_user_can('update_plugins')) {
// if there is updated transient
// any background update process can be run here.
// write your new version of code that will be run after updated the plugin here.
}// endif;
}// redirectToUpdatePlugin
/**
* {#inheritDoc}
*/
public function registerHooks()
{
// on update/upgrade plugin completed. set transient and let `redirectToUpdatePlugin()` work.
add_action('upgrader_process_complete', [$this, 'updateProcessComplete'], 10, 2);
// on plugins loaded, background update the plugin with new version.
add_action('plugins_loaded', [$this, 'redirectToUpdatePlugin']);
}// registerHooks
/**
* After update plugin completed.
*
* This method will be called while running the current version of this plugin, not the new one that just updated.
* For example: You are running 1.0 and just updated to 2.0. The 2.0 version will not working here yet but 1.0 is working.
* So, any code here will not work as the new version. Please be aware!
*
* This method will add the transient to work again and will be called in `redirectToUpdatePlugin()` method.
*
* #link https://developer.wordpress.org/reference/hooks/upgrader_process_complete/ Reference.
* #link https://codex.wordpress.org/Plugin_API/Action_Reference/upgrader_process_complete Reference.
* #param \WP_Upgrader $upgrader
* #param array $hook_extra
*/
public function updateProcessComplete(\WP_Upgrader $upgrader, array $hook_extra)
{
if (is_array($hook_extra) && array_key_exists('action', $hook_extra) && array_key_exists('type', $hook_extra) && array_key_exists('plugins', $hook_extra)) {
if ($hook_extra['action'] == 'update' && $hook_extra['type'] == 'plugin' && is_array($hook_extra['plugins']) && !empty($hook_extra['plugins'])) {
$this_plugin = plugin_basename(MYPLUGIN_FILE);// MYPLUGIN_FILE is come from __FILE__ of the main plugin file.
foreach ($hook_extra['plugins'] as $key => $plugin) {
if ($this_plugin == $plugin) {
// if this plugin is in the updated plugins.
// set transient to let it run later. this transient will be called and run in `redirectToUpdatePlugin()` method.
set_transient('myplugin_updated', 1);
break;
}
}// endforeach;
unset($key, $plugin, $this_plugin);
}// endif update plugin and plugins not empty.
}// endif; $hook_extra
}// updateProcessComplete
}
Please carefully read and modify the code above.
In your plugin file, call to Upgrader->registerHooks() method.
And write your code inside redirectToUpdatePlugin() method to work as background update process.
From my code, the procedure will be like this...
Running plugin v 6.0 -> update to 6.1 -> The code in 6.0 set transient that it is just updated.
Reload the page or click to anywhere in admin pages. -> Now v 6.1 is running. -> On the plugin loaded hook, it can detected that this plugin is just updated. -> Call to redirectToUpdatePlugin() method and background process start working here.

Related

Facing Fatal error with my Elementor website Fatal error: Access level to Molla_Element_Section::get_html_tag() must be protected

The Error my website displays is below:
Fatal error: Access level to Molla_Element_Section::get_html_tag()
must be protected (as in class Elementor\Element_Section) or weaker in
web.com/public_html/wp-content/plugins/molla-core/elementor/elements/section.php
on line 3668
As per the directory above the code on line 3668 is below:
/**
* Get HTML tag.
*
* Retrieve the section element HTML tag.
*
* #since 1.0
*/
private function get_html_tag() {
$html_tag = $this->get_settings( 'html_tag' );
if ( empty( $html_tag ) ) {
$html_tag = 'section';
}
return $html_tag;
}
Please help me fix this issue , I tried playing with elementor version (downgraded to check if this was the issue) but didn't help.
Take a look at Object Inheritance in php documentation:
The visibility of methods, properties and constants can be relaxed, e.g. a protected method can be marked as public, but they cannot be restricted, e.g. marking a public property as private.
Most likely Molla_Element_Section class inherits from Elementor\Element_Section and overwrites method get_html_tag. But it uses wrong access level.
get_html_tag method cannot be 'private' it has to be 'protected' or 'public'. As documentation says visibility cannot be restricted.
So I went ahead and rolled back the Elementor version to 3.3.1. Currently, everything works stable and the temporary solution seems working fine. If you are facing the same problem, here is what you need to do to downgrade Elementor.
Login to WP-Dashboard > Elementor > Tools > Version Control and Rollback version to 3.3.1
Click “Save” and make sure to clean the browser cache.
You should get a working website now!

No route found for POST ... : Method Not Allowed (Allow: PUT)

Currently, I am updating the system running on the existing Symfony 2.3 (currently 3.0.9), and checking the operation.
When I tried to change the state of an item to the selected state, I got an error.
Do you have any advice for determining the case?
Error Code
No route found for "POST /admin/hq/article/3999/articleStatus":
Method Not Allowed (Allow: PUT)
Code
ArticleController.php
/**
* Article status change
*
* #Method("PUT")
* #Route("/article/{ids}/articleStatus")
* #Secure(roles="ROLE_HQ_MANAGE")
*/
public function updateArticleStatusAction(Request $request, $ids)
{
return parent::updateArticleStatusAction($request, $ids);
}
Version
CentOS 6.7
PHP 5.6
Symfony3.0.9
I'm guessing you are using a web browser to submit a form and the action goes to /admin/hq/article/3999/articleStatus which only allows PUT operations (because of the #Method("PUT") annotation). Wheras submitting a form with a browser is a POST operation. Change that line to #Method("POST") and you should be fine.
Go vendor/symfony/http-foundation/Request.php and check line 80 in Symfony 6.2 and change this value from false to true
protected static $httpMethodParameterOverride = true;

Fatal error: Cannot declare class MYCLASS Woocommerce Settings

I have a website, and when I go to the WordPress admin page and click on woocommerce-settings it shows this error:
Fatal error: Cannot declare class WC_Settings_General, because the
name is already in use in
/(hosting)/website/wp-content/plugins/woocommerce/includes/admin/settings/class-wc-settings-general.php
on line 0 The site is experiencing technical difficulties. Please
check your site admin email inbox for instructions.
The beginning of class-wc-settings-general.php looks like this:
<?php
/**
* WooCommerce General Settings
*
* #package WooCommerce/Admin
*/
defined( 'ABSPATH' ) || exit;
if ( class_exists( 'WC_Settings_General', false ) ) {
return new WC_Settings_General();
}
/**
* WC_Admin_Settings_General.
*/
class WC_Settings_General extends WC_Settings_Page {
/**
* Constructor.
*/
public function __construct() {
$this->id = 'general';
$this->label = __( 'General', 'woocommerce' );
parent::__construct();
}
/**
* Get settings array.
*
* #return array
*/
public function get_settings() {
etc. The webpage url that is generating this error is: https://www.(mywebsite).com/wp-admin/admin.php?page=wc-settings
I need to know how to resolve this issue and get to the woocommerce settings. I have other websites that have woocommerce and do not have this issue, and I do not know where the other place it is declared would be.
If you need to know the list of plugins, please, let me know.
Please do not flag as a duplicate post as this is a very specific issue regarding woocommerce and WordPress that the other posts I have looked at (around 8 others) do not fix. I have checked for require to change to require_once
Thank you in advance!
I had exactly the same error, except it was pointing to line 0. I switched theme to Storefront and deactivated all plugins except WooCommerce, which fixed the problem... then switched the theme back and gradually added plugins back in to find out which was the problem.
Hopefully this can work for you as well - it was just a conflict with me on an old plugin I thankfully wasn't using any more anyway.

TYPO3 6.2: "Could not find a suitable type converter for "String" " exeption after update

TYPO3 was from a very old version updated to TYPO3 6.2. The most things are working now, but I have one own written extension that give me the following error:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1297759968: Exception while property mapping at property path "":Could not find a suitable type converter for "String" because no such class or interface exists. | TYPO3\CMS\Extbase\Property\Exception thrown in file /srv/vhosts.d/typo3_src-6.2.9/typo3/sysext/extbase/Classes/Property/PropertyMapper.php in line 106.
I have a list Method in one of the controller that generates a link:
<f:link.action action="show" arguments="{id : course.id}"> {course.name}</f:link.action>
This list method works, but when I want to open this generated link in the website I get the error from above.
I delete all stuff in the showAction method and also change the template to a basic output without special things. The method looks than like this:
/**
* action show
*
* #param String Course-Id
* #return void
*/
public function showAction($id){
}
But the error is still there. I have absolutely no idea anymore what is the problem. It would be great when someone have a different view and properly have some ideas where I can try to find out what the problem really is.
I think it needs to be
/**
* action show
*
* #param string $id Course-Id
* #return void
*/
public function showAction($id){
}
string lowercase and the argument $id must be specified as well
I want to share my solution way:
The first problem was that I don't know that there is a new way to delete the cache of the core. That I find out because of Jost comment in my answer with the "clear the cache from install tool". So I go in the Backend of Typo3 to edit a user and edit there my own under Options the TSconfig field. I add there a row with options.clearCache.system = 1. Now I can clear the system core over the flash symbol in the Backend of Typo3.
After that I try to change the #param String in #param string. I deleted the core cache and then I got a different error. I found out that this new error say that only arrays or objects are as parameters are allowed in the action method (See: http://wiki.typo3.org/Exception/CMS/1253175643).
So I deleted the parameter and follow the instruction on the website where the error is explained. So my new method looks as follow:
/**
* action show
*
* #return void
*/
public function showAction(){
if ($this->request->hasArgument('id')) {
$id= $this->request->getArgument('id');
}
// Do stuff with the id
}
And that works now :)

How to add last-modified/version for PHP code block using PHPDoc?

I'm developing a WP theme and I'm commenting my PHP code using PHPDoc. I would like to add versions of large code blocks, so the customer knows when it's updated.
Let's say I release initial version 1.0.0, then I update some code in version 1.0.2. How do I document that the code is changed? Will this be correct:
/**
* Code block #1
*
* #since ThemeVersion 1.0.0
* #version 1.0.2
*/
I'm not sure this is a correct way to use #version, since on the other hand I have another case when another block of code have not been changed after the update:
/**
* Code block #2
*
* #since ThemeVersion 1.0.2
* #version 1.0.0
*/
So not sure if this makes sense.. please let me know your thoughts.
Thank you.
Your use case is a reasonable use of the combination of both tags.
As such, I would expect your usage in Code Block #1 to mean:
this block was created in Theme v1.0.0
this block was last modified by Theme v1.0.2
(note that the current Theme version in use by the consumer could be v2.0.0, but these tag values still mean what they mean -- even if this installed Theme is v2.0.0, this code block #1 was added originally in v1.0.0, and was last changed in v1.0.2)
Now, on your Code Block #2:
#since ThemeVersion 1.0.2 should be telling me that the block was first created in Theme v.1.0.2
but #version 1.0.0 tells me it was last modified by v1.0.0... but that can't be right, because it wasn't even in the code until v1.0.2.
(if you set both tag values to 1.0.0, that would say to me "block #2 was created in v1.0.0 and has not been changed yet).

Categories