Daniele Alessandra

Hi,

Thank you for your question!

At the moment, the plugin doesn’t include an option to render the reaction template directly into the page without lazy loading. While we experimented with this approach in the past, it didn’t gain much traction, as most users preferred the current lazy load implementation.

That said, I’ve introduced new hooks in version 5.3 of the plugin (currently pending approval). These hooks allow for greater flexibility and could be used to completely customize the output of the reaction buttons. Once the update is live, I’ll test a potential snippet to see if it can achieve the behavior you’re looking for.

Feel free to check back in soon, or let me know if you’d like to be notified when the update is available!

Best regards,

Daniele

Hi Josh,

Thank you for reaching out—hope you’re doing great!

It’s awesome that you’re diving into customizations with PHP. Regarding your question, I’m happy to share that there is indeed an action hook available for reactions, very similar to the comment_post action in WordPress. This allows you to capture details like the reaction type, author, and link where the reaction occurred.

However, this specific feature is part of an enhanced version of the plugin designed to support more advanced use cases. You can explore the full list of available hooks and documentation here: https://da-plugins.helpscoutdocs.com/category/62-actions.

If you’d like more information or assistance in setting it up, feel free to let me know—I’d be happy to help.

Warm regards,

Daniele

It’s exactly that. The plugin leverages WordPress hooks to attach the widget. Based on settings the widget could be added to:

• WordPress core elements
  • the_content
  • the_excerpt
  • comment_text
• BuddyPress elements
  • bp_activity_entry_meta
  • bp_activity_comment_options
  • bp_after_group_header
  • bp_after_member_header
• BBPress elements
  • bbp_get_forum_content
  • bbp_get_forum_content
  • bbp_get_forum_content
• WPFORO elements
  • wpforo_content_before
  • wpforo_content_before
  • wpforo_template_buttons

If you have a widget or a theme that overrides the original behaviour, the widget will not be visible, unless you add it in other ways.

Here are two different ways to add reactions widget programmatically:

// Call renderer from class
 echo DaReactions\Frontend::getButtonsPlaceholder( 'post', 1 );

// Use shortcode
 echo do_shortcode( '[reactions type="post" id="1"]' );

Thank you for reporting the bug, feel free to contact me anytime.

Hello Chad, the error is weird, something is missing here.

It looks like you are running the free version of the plugin along with the premium version (all functions with suffix __premium_only are stripped out from free version).

Please download latest zip file from your Freemius dashboard: https://users.freemius.com/

If you experience difficulties logging to your Freemius panel I could send you the zip file directly, but on a private mail.

Hi Chad,

Thank you for using DA Reactions, and for taking the time to provide such detailed feedback—it’s greatly appreciated.

To enable or disable the ability for users to “un-react” to a post, you already found the correct place in your database, however you should find the relevant option in the plugin settings under Reactions > General Settings > User:

[Your Site's Domain]/wp-admin/admin.php?page=da-reactions_general_settings&tab=user

Regarding the issue you’re experiencing: the reactions are not designed to behave differently based on whether they are presets or custom ones, so this behavior is unexpected. While I haven’t encountered this issue before, I’ll attempt to reproduce your use case on my end to better understand the problem.

In the past, we’ve had a similar issue that was related to Unicode characters in reaction labels, but this was resolved in a prior release. Based on your description, this doesn’t immediately seem to be the same issue, but I’ll investigate further.

It would also be helpful to take a closer look at your specific site setup or receive additional details about your reactions. If possible, feel free to send a screenshot of the reactions setup or any other relevant information to [email protected].

If this turns out to be a bug, we hope to identify and resolve it in time for the next plugin release, scheduled for the next couple of weeks.

Thank you again for bringing this to our attention! Let me know if you need further assistance in the meantime.

Best regards,
Daniele Alessandra

Hi Josh,

Thank you so much for your kind words and for using DaReactions! ??

The issue you’re experiencing happens when the count badge overlaps the reaction icon, making most of the icon unclickable. This overlap is particularly noticeable when reducing the reaction button size, as the badge doesn’t scale proportionally.

To fix this, you can adjust the size and positioning of the count badge using custom CSS. I’ve detailed the steps in this support article:

How Can I Resize the Count Badge?

In short, you can resize the badge by modifying its font size and adjusting its position to ensure it no longer blocks the reaction icon. For example, you might add this CSS to your site:

div.da-reactions-container div.reactions div.reaction .count {  
    font-size: 0.3em;  
    position: relative;  
    top: -5px; /* Adjust as needed */  
    background: transparent; /* Optional, for better appearance */  
}

This can be added via Appearance ? Customize ? Additional CSS in your WordPress admin. Once applied, you should be able to click anywhere within the reaction icon to cast your vote.

Please let me know if this resolves the issue or if there’s anything else I can assist with!

Warm regards,

Daniele Alessandra

Hi Betty,

Thank you for reaching out. The widget ‘Display Contents with Most Reactions’ is indeed still available. However, since the update to WordPress 6.6, it is marked as a ‘legacy widget,’ and there might be instances where it could be hidden. If your theme is configured to use only widgets created in the new block format, it may have hidden this legacy widget.

Updating this widget is on my to-do list, but until now, it hasn’t been reported as non-functional. To help me investigate further, could you kindly provide more information about your setup (WordPress version, DaReactions version, and the name and version of your theme)? This will allow me to run tests with your specific configuration.

Thank you for your collaboration and patience.

Best regards,
Daniele

I’m really happy to hear that everything is working perfectly for you! ?? It’s always rewarding to know that my work is helping people.

At the moment, over 200 people are actively using the plugin, but only 14 have taken the time to leave a review, and one of them gave 1 star. Feedback is incredibly valuable as it helps the plugin grow and improve.

Thanks again for your kind words and support! ??

Hi @betty_ ,

Thank you for reaching out and reporting this issue. I’m glad you found my plugin helpful!

Great news! The issue you’ve described with the hamburger button disappearing on mobile after the latest update has been resolved in version 5.2.1. Please update your plugin to the latest version and let me know if the problem persists.

I appreciate you taking the time to report this bug. Your feedback is invaluable to me and helps me improve the plugin. In fact, while investigating this issue, I discovered the very interesting wp_kses function, which is the most secure way to handle allowed and disallowed tags in output. Thanks to your report, I’ve been able to enhance the plugin’s security and code quality.

Quality and security are my top priorities. If you encounter any other issues in the future, please don’t hesitate to report them.

Thanks again for your support!

Ciao Betty,
[English below]

Ho verificato che il problema esiste ed è causato dall’uso della funzione wp_kses_post per sanificare l’output di tutti i widget. Purtroppo, questa funzione rimuove i tag <svg> dal markup, poiché considerati potenzialmente insicuri.

Sto già lavorando a una soluzione che permetta di risolvere il problema senza compromettere la sicurezza, e ti ringrazio per averlo segnalato.

Per favore, se possibile, apri un nuovo topic dedicato a questa segnalazione. In questo modo sarà più semplice tenere traccia dell’avanzamento della risoluzione.

Grazie ancora per aver scritto in italiano e, soprattutto, per utilizzare il mio plugin! Aggiungo qui di seguito la traduzione in inglese della nostra conversazione, così da renderla accessibile a tutti.

[English]

Betty wrote:
After the latest update, the hamburger button is no longer visible on mobile. A loading icon appears and then disappears… Thank you for your plugin!

Response:
Hi Betty,

I have confirmed that the issue exists and it is caused by using the wp_kses_post function to sanitize the output of all widgets. Unfortunately, this function also removes <svg> tags from the markup, as they are considered potentially unsafe.

I am already working on a solution that will resolve the issue without compromising security, and I appreciate you bringing it to my attention.

Please, if possible, open a new topic specifically for this report. This will make it easier to track the progress of the fix.

Thank you again for writing in Italian and, most importantly, for using my plugin! I am including an English translation of our conversation to make it accessible to everyone.

Hi Patrick, after numerous experiments, I’ve discovered two things: first, when using SHORTINIT with a minimal version of WordPress, I have to give up knowing who the user is, and because of that, I can’t determine in advance if you’ve already voted for the content you’re viewing. Second, there isn’t much difference in response times, and unless you’re using plugins that significantly slow things down, you shouldn’t experience any noticeable delays.

Additionally, I’ve recently released version 5.2.0, which, among other things, replaces the old filesystem-based cache system with wp_cache, improving performance a bit. Finally, I’d like to inform you that version 5.2.1 will be released in the coming days, addressing all the warnings reported by Plugin Check, which is now part of the deployment process. I’ll mark this issue as resolved.

Hello Faisal, thank you for your suggestion!

The ability to use custom SVG code as a reaction button is already available in the premium version of the plugin. In the paid version, you can select any image from your media gallery as a reaction icon, and if your site allows SVG uploads, you can use SVGs freely.

Also, as long as the SVG file doesn’t enforce a specific color, the color options will also work with it.

At this time, I don’t have plans to include this feature in the free version, but feel free to reach out if you have any other questions!

Thank you for your patience, I can confirm that removing that part didt the trick, now the function looks like this:

	/**
	 * Invoked from frontend to load button asynchronously
	 * Must not validate nonce because it is not a security issue
	 * And, most of all, some cache plugin may not work properly
	 *
	 * @since 1.0.0
	 */
	public function loadButtons() {
		header( "Cache-Control: no-store, no-cache, must-revalidate, max-age=0" );
		header( "Cache-Control: post-check=0, pre-check=0", false );
		header( "Pragma: no-cache" );

		$_POST     = filter_input_array( INPUT_POST, FILTER_SANITIZE_FULL_SPECIAL_CHARS );
		$item_id   = (int) $_POST['id'];
		$item_type = sanitize_text_field( $_POST['type'] );

		echo Frontend::getButtons( $item_type, $item_id );

		exit();
	}

I’m going to run some tests, but basically this is the fix.

Updated version will be released for everyone in the next few days.

Hi Patrick,

Thank you for reporting this issue.

Surely this is a bug that I need to solve as soon as possible, I’m thinking of removing nonce validation on first call and generating a new nonce with every new request. I’m going to work on it in the next few days. In the meantime, to resolve the issue temporarily, you could try:

• Disabling the cache: For the specific page or for the shortcode itself.
• Editing source to remove nonce validation: As a temporary workaround, inside classes/DaReactions/Ajax.php find and remove the block if ( ! $valid_nonce ) { ... } inside loadButtons function.

I’ll keep you updated on the progress of the fix and let you know as soon as it’s available.

Thank you for your patience and understanding.

Best regards, Daniele