Recently I am trying to understand the codebase of a custom wordpress plugin.
Some syntax of add_action() looks confusing to me.
add_action( 'after_plugin_row_wc-smart-cod/wc-smart-cod.php', array( $this, 'add_warning' ) );
I know the first parameter of add_action() is the name of the action to which the function 'add_warning' of $this object is hooked.
But in the above example the first parameter is the name of a php file, instead of an action name.
What does it mean ?
Thanks.
The first parameter to an action is a string. Generally it is something like wp_footer or before_send_email but there really isn't any restrictions on it. For instance, in my company's code, we often use slashes to give the action a (fake) namespace such as company/plugin-name/class/action but this is 100% arbitrary from WordPress's perspective.
Back to your example, however, there actually is a specific pattern from WordPress for that specific hook which you can see here. Every plugin in WordPress has an "entrance" or "plugin" file that boots up the entire plugin. Because most plugins live in a sub-folder, it is often plugin-name/plugin-name.php or plugin-name/index.php but it is ultimately up to the plugin author.
Most people use that specific action to add special messages to their own plugin's row in the general listing of plugins. The plugin you mentioned is using it to give a warning to users with a very specific version of the plugin installed.
Related
I've written a Wordpress plugin. I hook to some actions from another plugin and everything works, but I want to know, when I deactivate my plugin, do these actions still get called and executed, or does Wordpress remove them automatically?
I tried removing actions on deactivate hook, but something doesn't make much sense to me. I'm using OOP.
When adding an action, I add the callable with an array like this in a registerActions function:
add_action('gform_validation_' . $form_id, array($this, 'formValidate'));
and remove it in unregisterActions function:
remove_action('gform_validation_' . $form_id, array($this, 'formValidate'));
My problem:
The registerActions and unregisterActions functions are called to different instances of the same class. Is remove_action actually removing the same action I've created?
I couldn't find anything discussing this on the internet and it really left me wondering.
Edit: I guess I could store the instances and actually call the registerActions and unregisterActions functions on the same instance. But how do I do it properly? I could also make action functions static.
I'm using a WordPress plugin for accepting online bookings (Appointment Hour Booking) and I need to attach a file to the emails sent after submitting the booking request (a PDF file with the general booking terms). I already applied a solution by editing the calls to the wp_mail() function in this way:
wp_mail(trim($payer_email), $subject, $message,
"From: ".$from."\r\n".
$content_type. "X-Mailer: PHP/" . phpversion(),
array(WP_CONTENT_DIR . '/uploads/agreement.pdf'));
The above works but everytime the plugin updates the file is overwritten and I've to reapply the code modification again. There is a better way to do that without being affected by the plugin updates or there is a way to prevent partially or completely a plugin update in WordPress?
Thank you in advance for any help.
Disabling the plugin update isn't a good idea, you may lost important compatibility or security updates. The way the call to the wp_mail() was modified also causes other attachment-related features stop working. The plugin you mention has a filter that can be used to modify the list of attached files, you can put the following code for example into your theme’s functions.php file:
add_filter( 'cpappb_email_attachments', 'my_attach_function', 10, 3 );
function my_attach_function( $attachments, $params, $form_id )
{
$attachments[] = WP_CONTENT_DIR . '/uploads/agreement.pdf';
return $attachments;
}
With the above code located out of the plugin files your file is added to the list of attachments without removing other attachments and locating the code out of the plugin files will prevent being overwritten by the plugin updates.
Your options are:
Fork the plugin and customize it to your needs.
Ask the team behind the plugin to implement a filter hook to allow customizing the headers passed to the wp_mail() function (so you can then attach files to e-mails).
Keep doing what you have been doing until now.
I like option two the best because:
It allows you to customize the behavior of the plugin from the outside, and,
Your changes will survive plugin updates.
I want to perform quick rewrite slug update for my custom post type on the fly. So I use code like in my theme's functions.php:
$no = get_post_type_object($pt_slug);
$no -> rewrite['with_front'] = false;
$no -> rewrite['slug'] = $slug;
register_post_type($pt_slug, $no );
Which is hooked to 'init' add_action('init', 'check_post_type_rewrite_url');
There is large code so I write only issue part in here.
register_post_type returns object with updated slug. I understand it means my custom post type was updated, but it was not. Existing post type still has its old rewrite slug. Should I add something special for rewrite rules to save changes and make it work? Or there is specific way to register/update post types with rewrite slug so it worked?
The way you solved the issue - by using flush_rewrite_rules - is technically correct but not recommended. As stated in the doc:
This function is useful when used with custom post types as it allows for automatic flushing of the WordPress rewrite rules (usually needs to be done manually for new custom post types). However, this is an expensive operation so it should only be used when absolutely necessary.
So you shouldn't keep your flush_rewrite_rules() call in your init hook, as it will regenerate all the rewrite rules at every page load, which is really badly ressource consuming.
Usually it's enough to just visit the Permalinks Settings page to flush the rules - so if you change again your CPT slug in the future, just visit the page once.
If your slug could change dynamically, then you can make use of flush_rewrite_rules(), but you need to use it carefully - it shouldn't be called on every page load, but could be used by a periodic cron job, or on plugin activation / deactivation, depends of the case.
I am writing a WordPress plugin that has an AJAX element to it - blocks of HTML are fetched by the front end from the plugin using AJAX.
I am having difficulty joining up the pieces here, and I suspect it is just a terminology issue. How would I implement a page completely provided by the plugin?
The content of the page will be HTML - the plugin can generate this in response to POST or GET parameters.
There needs to be a route to this page. The route does not have to be user-friendly or a REST style - just some kind of URI that gets to the plugin. Is there perhaps a way to register a custom page with an arbitrary name, without having to create it as a WP post?
I would like all this to be self-contained in the plugin, so should not involve the administrator having to create posts or pages, or have to add anything to the theme.
Ideally I would avoid any URLs that go into the wp-admin directory. End users don't belong in here.
I would strongly suggest referring to https://codex.wordpress.org/AJAX_in_Plugins#Ajax_on_the_Viewer-Facing_Side
You need to have a php script in your plugin directory that returns what you request, and you need to determine that url at run time for reference in your ajax. The above link gives an example for enqueuing and using wp_localize_script() to provide the url for your custom php script.
wp_enqueue_script( 'ajax-script',
plugins_url( '/js/my_query.js', __FILE__ ), array('jquery') );
// in JavaScript, object properties are accessed as
// ajax_object.ajax_url, ajax_object.we_value
wp_localize_script( 'ajax-script', 'ajax_object',
array( 'ajax_url' => plugins_url( '/php/myapi.php' ));
Your javascript file will be included on every page and will listen for events on the page which require a block of HTML, as you've described it.
Your file myapi.php then needs to take a request, probably using a query string, get the appropriate content from the wordpress api, and respond with said content, which your javascript will put into place.
To have access to the wordpress api as well though, you have two options:
Force wordpress to run starting with your file, by including wp-load.php. This is probably not the cleanest way.
Set up a custom page or slug to direct to your plugin.
I would advise the second option, and advise a slug, in which case you may find this post helpful: wp_rewrite in a WordPress Plugin
From Jason's comment, based on the link above:
The rewrite rules are mentioned a lot, but are really a distraction -
they just help to make URLs look more "friendly", which was not an
objective here. The key is: register a custom GET parameter; look for
that parameter early in the page rendering process; if you find the
parameter is set, then output/echo stuff and die(). There are a
number of hooks that can be used to look at the parameters, chosen
dependin on how much you want WP to set up and process first.
I'm trying to set the default Image Link URL for my WP users so that it doesn't include the url link as a default. I've done some research, and I know the function is in the wp-admin/options.php:
update_option('image_default_link_type','file');
Rather than mess with the core files, I'd like to put this into the functions.php, but never know the proper way to implement stuff like this! This is what I have so far in my functions.php:
<?php
update_option('image_default_link_type','none');
?>
This obviously doesn't work: it needs the proper setup! What is the correct way to implement this in functions.php?
Also: I'd like to know the strategy for figuring out how to implement functions like this in the future by myself? For example, I never know whether or not I'm supposed to use add_filter or do_action, and how I need to pass the parameters. I've yet to find a book or post out there that explains this very well, and can show me by example. Any good leads on this would be awesome too!
Start with the Wordpress codex. Visit the plugin API (which is really what you are doing) that explains Hooks, Actions and Filters. Then see the Action Reference which provides your list of hooks.
Here you will find the hook update_option_OPTIONNAME. Description from codex:
Runs after a WordPress option has been update by the update_option
function. Action function arguments: old option value, new option
value. You must add an action for the specific options that you want
to respond to, such as update_option_foo to respond when option "foo"
has been updated.
Adding code from asker's comment:
function inventory_linkurl_setting() {
update_option('image_default_link_type','none');
}
add_action('admin_init', 'inventory_linkurl_setting'); ?>