I've recently upgraded a site to Drupal 7.59 with install profile:
Commerce Kickstart (commerce_kickstart-7.x-2.54)
Previously there was a function that had been added to the core which has now been removed because of the upgrade. This shouldn't have been added to the core and I'm not sure why it was. I've added this function back in and its not doing what it did previously so I'm not sure what other changes I would need to make to get it to work.
Here's the function which is found in /profiles/commerce_kickstart/themes/commerce_kickstart_admin/template.php -
function commerce_kickstart_admin_commerce_price_formatted_components($variables) {
// Add the CSS styling to the table.
drupal_add_css(drupal_get_path('module', 'commerce_price') . '/theme/commerce_price.theme.css');
// Build table rows out of the components.
$rows = array();
foreach ($variables['components'] as $name => $component) {
$rows[] = array(
'data' => array(
array(
'data' => $component['title'],
'class' => array('component-title'),
),
array(
'data' => $component['formatted_price'],
'class' => array('component-total'),
),
),
'class' => array(drupal_html_class('component-type-' . $name)),
);
}
if($variables['components']['discount']['price']['amount']){
unset($rows[0]);
unset($rows[2]);
}else{
$rows = array_splice($rows, 2);
}
return theme('table', array('rows' => $rows, 'attributes' => array('class' => array('commerce-price-formatted-components'))));
}
Can anyone give any pointers as to how to get this working? It doesn't appear to even be getting invoked.
Additional info from the comments:
it's a function in the profile?
yes
Was the function added afterwards (as in "Never hack core")?
Yes, looks like it.
Or was it removed by the maintainers?
Doesn't look like this was ever part of any official release
Do you use some version control system like Git?
Yes. This function was added on 14/05/2015 12:18 according to the repo.
Have you checked the profile's release notes and issue queue?
Had a look but don't see anything.
Thanks for adding the extra info!
Well, if this really was custom code than it should never have been added to the profile in the first place. Never ever add custom code to any core or contrib file. As it's going to be deleted as soon as you update. Like it has happened to you.
I guess the most important part of this custom function was drupal_add_css(drupal_get_path('module', 'commerce_price') . '/theme/commerce_price.theme.css'); and that this commerce_price.theme.css maybe also got deleted.
Apart from that it's hard to tell from far and I'm not an expert in the commerce module. So, what I would do now is to narrow down the issue systematically.
Restore your repo to a time in history before this module got updated and get the site running.
Find out what this code is doing exactly, what other functions or flows are involved. Maybe with the help of the Devel module and the mighty dpm() function.
Try to rebuild the custom code from the profile in a custom module.
Then reset the repo to the current state and see if your custom module's code is still firing. If not, debug it to match the updated profile's code.
Apart from that, find the person who added the code and ask them why and what this code is doing. And tell them to never ever again hack core or contrib code :)
Good luck!
Related
I have created a drupal 9 custom module with new content types and fields. I would like to create a sample node when the module is installed.
What is considered the best method for creating a sample node programatically?
I looked at using migrate and migrate_tools and building YAML files. This is promising but have issues with current versions of drush 10.6 and migrate 5. It looks like there is a fix in dev, but I wondered what everyone else does. My preference is to not depend on a module, unless there are compelling reasons (like easy maintenance of test cases or sample data)
thanks
You have to use a hook:
When you install the module, use this hook hook_install
When you update the module, use this hook hook_update_N
In the hook, you have to implements the correct logic:
$node = Node::create([
'type' => 'article',
'title' => 'Druplicon test',
'field_image' => [
'target_id' => $file->id(),
'alt' => 'Hello world',
'title' => 'Goodbye world'
],
]);
$node->save();
Complete message:
Notice: WP_Scripts::localize was called incorrectly. The $l10n parameter must be an array. To pass arbitrary data to scripts, use the wp_add_inline_script() function instead. Please see Debugging in WordPress for more information. (This message was added in version 5.7.0.) in /home3/dduconne/public_html/wp-includes/functions.php on line 5313
Appeared just after updating wordpress to 5.7.0
Ok since there quite a few views and the previous answer just throws it under the rug.
Yes it is a warning now, but who knows what will happen, it is a warning for a reason, disabling something is not resolving it, there is a reason devs set it as a warning for now.
While we wait for plugin developers to resolve it on their ends, you can find out the source of the problem by enabling php_xdebug in php. I recommend not leaving it after debugging, as I am not sure about the performance cost of it being enabled.
php_xdebug will return a stack of all files affected, from there you can trace it to the source of the problem. The fix once found the source is quite easy. Culprit most likely is wp_localize_script() which requires last parameter to be an array()!
So you would find something like this:
wp_localize_script( 'handle', 'object_name', 'l10n_culprit_string' );
Which should be turned into:
wp_localize_script( 'handle', 'object_name', array( 'l10n_culprit_string' ) );
Solution to problem came from here
This is a new warning appearing in Wordpress 5.7. If you don't want to see it, and still want to have WP_DEBUG set to true, it is possible to disable the message by adding the following for example in your theme's functions.php:
add_filter('doing_it_wrong_trigger_error', function () {return false;}, 10, 0);
It is now a notice if you are using wp5.7 and php7.4, but changing to php8 it may gets reported as error. For me, when i changed (in my own code) the passed value to array (yes, probably some changes also needed in the involved js), everything worked just fine.
This is because one of the PHP script in your wordpress installation uses wp_localize_script() to pass some PHP variables to a JS script through AJAX request, and it's not good practice anymore.
This can be inside a plugin or inside your custom theme or child-theme's functions.php.
If wp_localize_script() is not in a child-theme or custom theme's functions.php, try this :
backup your website
deactivate all plugins
reactivate them one by one until you get the notice again
when the notice shows up again, this means the plugin you just reactivated uses wp_localize_script() the wrong way
if it's not up-to-date, try updating it (if you want to) : maybe the notice is going to disappear
if it's already up-to-date, or you don't want to update it, search inside wp-content/plugins the corresponding plugin's folder
open it and try to find the file(s) where wp_localize_script() is called, you can also use CLI with your server's terminal to find string in files. For example, if your server runs on Linux : grep -H -r "wp_localize_script()" /root/pathtopluginfolder | cut -d: -f1
Then, replace the code as follow :
Old one should look almost like this :
wp_enqueue_script( 'wpdocs-my-script', 'https://url-to/my-script.js' );
wp_localize_script( 'wpdocs-my-script', 'MYSCRIPT', array(
'ajaxUrl' => admin_url( 'admin-ajax.php' ),
'otherParam' => 'some value',
) );
New one :
wp_enqueue_script( 'wpdocs-my-script', 'https://url-to/my-script.js' );
wp_add_inline_script( 'wpdocs-my-script', 'const MYSCRIPT = ' . json_encode( array(
'ajaxUrl' => admin_url( 'admin-ajax.php' ),
'otherParam' => 'some value',
) ), 'before' );
Note that you need to add 'before' as the third parameter to the wp_add_inline_script function.
Once it's done, the notice shouldn't show anymore. If so, contact the plugin dev to tell him about this so that it can be part of the next update.
For more informations, see Jules Colle's comment on this page : https://developer.wordpress.org/reference/functions/wp_add_inline_script/
There are some 3rd party Wordpress plugins that do not support automatic updates. So, if you have v1.0 of a plugin already installed and you try to install a new version (e.g. v1.1), you will end up getting the message:
Destination folder already exists. /home/.../.../...
This leaves two options, neither of which i'd like to use: Uninstall & re-install the plugin, or manually upload the new files via FTP.
In /wp-admin/includes/class-wp-upgrader.php line 428 I see this code:
public function install_package( $args = array() ) {
global $wp_filesystem, $wp_theme_directories;
$defaults = array(
'source' => '', // Please always pass this
'destination' => '', // and this
'clear_destination' => false,
'clear_working' => false,
'abort_if_destination_exists' => true,
'hook_extra' => array()
);
$args = wp_parse_args($args, $defaults);
...
Is it possible to add a line to my theme's functions.php file to re-declare 'clear_destination' as true, and thereby forcing Wordpress to overwrite plugin files when I upload them?
Thanks
I kept digging and think I found a solution. If I create a custom plugin I can re-declare the options by using the 'upgrader_package_options' filter:
function override_plugins( $options ) {
$options['clear_destination'] = true;
$options['abort_if_destination_exists'] = false;
return $options;
}
add_filter( 'upgrader_package_options', 'override_plugins' );
No, that's not possible. You would need to edit the core files.
However you could install a plugin on the relevant site(s) that would take care of the problem for you: http://w-shadow.com/blog/2010/09/02/automatic-updates-for-any-plugin/
Or you could incorporate an updater framework within your plugin, which makes it possible to serve updates from private repos(eg not WP): https://github.com/afragen/github-updater
Alternatively, you could use something like WPPusher, which can automatically update the plugin whenever an update is pushed to Github / BitBucket. I personally use this plugin for testing dev versions of plugins I'm building.
In addition to Phill Healey's answer, an alternative service to WPPusher dedicated to Wordpress Developement is WP Package Editor (WP2E)
The Package Installer overwrite plugin source and log installations into a panel to monitor script versions, upgrades and status.
I am running into an issues with dump() in Twig.
I am not able to completely dump the values of the object that I am returning to my twig template. My object, as defined below, is built up of a product object, qty key/val, OnOrder key/val and avgUnitCost key/val.
I AM able to use dump(qty), dump(OnOrder), dump(avgUnitCost) and see the values of these.
I AM NOT able to use dump() on product to see the key/val of the product object. All I get is a white page of death.
I have read elsewhere on stack that it is a memory issue in the php.ini file. This does not seem to fix the issue, I set mine 1024M and it still times out and gives me the white screen.
I have also read this guys article on the same issue: http://hectorpinol.com/twig-debug-in-symfony-2/ ... He thinks it is a "bidirectional association problem".
In any case, here is the code that I am using to pass the object and render my twig template...
return $this->render('TestBundle:Event:view.html.twig', array(
'heading' => 'View Product',
'product' => $product,
'qty' => $qty,
'OnOrder' => $OnOrder,
'avgUnitCost' => $avgUnitCost,
));
Here is the guts of my question:
How can one effectively use twig to access the elements of an object, whether it be dump or some other method. I need to be able to see all of the elements in the object so that I can place them on the page as I need.
Thanks so much for your help!!!
Check LadybugBundle. You can dump everything.
Try adding a break point in twig_var_dump:
/vendor/twig/twig/lib/Twig/Extension/Debug.php (at the bottom)
Then you can use the functionality of your debugger...
Look at this answer: https://stackoverflow.com/a/29302069/4102223
It is my approach to solve this problem, only few lines must to be changed in one place (it is easier because no need to include new bundles and read its documentation).
I'm developing a Wordpress plugin that requires updates, although the plugin version is being checked from my server. There are several plugins that I have developed which use the exact same server to check for new versions. The problem I'm experiencing is that when all the plugins require an update and I click View Details, one of the plugins will show details of the update (version, description, and etc), but the other plugins won't show any information. After some debugging I can see that the server is returning data for sure.
My question is, how can I apply the plugins_api filter multiple times without it conflicting with the other plugins?
Your observation is right. It is not obvious. Even the book of Brad and Ozh (Plugin development ed. Wrox) includes an error in the example on page 267 in the chapter "make your own API repository".
Like you, I spent (lost) time to find the issue with a two plugins in alternate API...
The solution:
Remember that that first parameter in the WP filter is the original value passed to the filter.
So to concatenate the filters (listed by plugins using alternate api)... the first line must be:
function xiliw_altapi_information( $false, $action, $args ) {
$plugin_slug = plugin_basename( __FILE__ );
// Check if this plugins API is about this plugin
if( $args->slug != $plugin_slug ) {
return $false; // var to conserve the value of previous filter of plugins list in alternate api. fixes book error not val false
}
// POST data to send to your API
$args = array(
'action' => 'plugin_information',
'plugin_name' => $plugin_slug,
'version' => $transient->checked[$plugin_slug],
'registration' => $this->registration
);//../..
By doing this test, each time the list of hooks is called, only one - the concerned plugin - gives the right answer to display the information for the splash window.
If I have time, I probably will publish soon a more complete article about a class to manage this alternate powerful API and how to add it to a -private- plugin.