GamiPress Conditional Notifications - WordPress Plugin

How to Set Up GamiPress Conditional Notifications for Precise On-Site Alerts

GamiPress Conditional Notifications is not meant for yet another generic message in the corner of your site. It is built for specific moments: when a user reaches a target points balance, unlocks an achievement, completes a full set of achievements of the same type, or advances to a rank. In this guide, we will walk through how to add these notifications to an existing GamiPress setup, which dependencies to verify before installation, how to configure conditions, tags, styling, and display limits, and how to confirm that a notification actually fired.

This guide does not repeat the product's short description. Instead, it focuses on a practical workflow: from preparing points, achievements, and ranks to testing a scenario in which a user receives a notification after reaching a threshold. We will also cover common issues separately: the notification does not appear, shows up for the wrong user, repeats more often than expected, loses its styling, or conflicts with caching or the theme.

The core idea is simple: a conditional notification is only useful when it is tied to a real user action and does not turn into noise. That is why this guide focuses not only on admin-panel settings, but also on the logic behind them: which event to choose, what message to write, which tags to insert, how to limit repeats, and how to verify the result with a test account.

What Problem a Conditional Notification Solves in GamiPress

In a standard GamiPress setup, the plugin builds a reward system around points, achievements, ranks, requirements, and events. A user does something on the site, the engine records the action, awards points, or unlocks an achievement. Standard notifications report that a reward was granted. GamiPress Conditional Notifications adds a more controlled layer: the administrator defines the exact condition that should trigger a specific message.

This matters for projects where the same event can carry different meaning. For example, a basic points award does not always need a separate message, but reaching a 500-point threshold might be a good time to prompt the user to unlock a new course, visit the rewards catalog, or check the next rank. The strength of this add-on is that the message is tied to the user's current state, not just to an abstract record of activity.

According to the official documentation, Conditional Notifications works on top of GamiPress and requires the Notifications add-on to be installed. It is not a standalone push service and it is not a replacement for email campaigns. It displays live notifications on the site when the selected condition is met, while the visual layer is inherited from the Notifications add-on settings and can be overridden for an individual conditional notification when needed.

How a conditional notification differs from a standard reward notification

A standard notification answers the question, "What just happened?" The user earned points, completed a step, or unlocked an achievement. A conditional notification answers a different question: "What message should appear in this situation?" That difference changes the way you configure it. You are not just enabling a nice popup. You are designing a small communication flow: event, text, personalization, style, limit, and result verification.

The documentation lists the conditions you can build on: reaching a points balance, unlocking a specific achievement, unlocking any achievement of a selected type, unlocking all achievements of a selected type, and reaching a specific rank. Each option reveals additional fields tied to the chosen condition. That makes it possible to avoid one generic message for every reward and instead show different messages for different stages of user progress.

When this add-on is especially useful

Conditional notifications work best when the user needs to notice the next step. In a learning project, that might be a prompt after a badge is unlocked. In a community, it could be a message after reaching a rank. In a loyalty-based store, it could be a balance reminder when the user has earned enough points for a reward. In a content-driven site, it might be a subtle prompt after a series of actions such as comments or visits, as long as those events are already configured through GamiPress or its integrations.

At the same time, this add-on does not solve problems that belong to another category. It does not create your points and ranks for you, it does not replace your gamification strategy, it does not send emails instead of Conditional Emails, and it does not manage BuddyBoss or BuddyPress notifications like a native social feed. Its role is narrower: display a personalized on-site message at the moment GamiPress detects a matching condition.

Who This Add-On Fits and When Another Approach Makes More Sense

Before installation, it is worth taking an honest look at how mature your GamiPress setup already is. Conditional Notifications becomes most valuable when your site already has a clear points, achievements, or ranks structure, and the user journey is mapped out at least a few steps ahead. If the project is still testing the idea of gamification and has not yet decided which actions should be rewarded, it is better to first configure the core point types, achievement types, and events.

For a site owner, the add-on is convenient because it does not require building a separate messaging system. For an instructor or community manager, it works well as a prompt mechanism: "you unlocked a new level," "your next task is now available," or "you completed all achievements in this category." For a developer or administrator, it is a way to reduce manual messaging and plug the response into an existing reward engine.

Good use cases

• Your site already uses GamiPress points, achievements, or ranks, and you need to guide the user toward the next step after an important event.
• Your team wants to show different messages for different achievement types instead of using one universal template for every reward.
• You need personalization through tags such as points balance, achievement title, reward link, or type-specific data when available in your configuration.
• It is important to limit how many times a message appears so it does not show forever and annoy returning users.

When the product may not be the right fit

If you need emails rather than on-site popup notifications, it makes more sense to look at GamiPress Conditional Emails or your broader email setup. If the notification needs to appear inside BuddyBoss or BuddyPress as part of the social platform itself, it is better to evaluate BuddyBoss Notifications or BuddyPress Notifications. If you need a complex chain of actions across multiple plugins, where one event triggers several automations, Conditional Notifications may be too narrow for the job.

A practical pre-check: describe your use case in one sentence using this pattern: "when the user does X, they should see Y because the next step is Z." If X can be expressed through a supported GamiPress condition, and Y truly needs to be a live on-site notification, this add-on is a good fit.

What to Check Before Installing It on a WordPress Site

Preparation matters more here than it may seem. Conditional Notifications does not start from scratch: it depends on GamiPress, the Notifications add-on, and already configured gamification entities. If your points, achievements, or ranks were created inconsistently, your conditional notifications will be just as unpredictable for editors and just as confusing for users.

Core dependencies

First, make sure the main GamiPress plugin is installed and active. The official WordPress directory confirms that GamiPress provides the underlying system for points, achievements, ranks, events, blocks, shortcodes, logs, and integrations. Then verify that the Notifications add-on is installed, because the Conditional Notifications documentation explicitly lists it as a dependency. Without it, the live notification layer is missing.

Next, confirm that the site already has at least one real entity that the condition can target:

• A point type and a clear balance threshold if you want to notify users when they reach a total.
• A specific achievement if the message should appear after unlocking one particular reward.
• An achievement type if the message is tied to any reward in a category or to completing all achievements of that type.
• A rank type and a specific rank if the notification should accompany a move to the next level.

A test user and a controlled scenario

Do not test your first conditional notification on an administrator account that has already earned half the rewards and completed old events. Create a separate test user account or use a staging site. For a clean test, you need to understand the starting state: points balance, unlocked achievements, current rank, and activity log. Otherwise, you will not be able to tell whether the issue comes from the configuration or from the fact that the user already satisfied the condition earlier.

Cache, minification, and theme behavior

Live notifications depend on frontend scripts and a theme that behaves normally. If your site uses aggressive page caching, script combining, delayed JavaScript loading, or a heavily customized theme, make sure to test the notification after installation in a regular browser, in incognito mode, and as a test user. The official Notifications add-on page also warns that disabling live checks fully disables the live notification feature, even though it may reduce server load.

For the initial rollout, it is usually better not to change questionable optimizations yet, but you should know exactly where they are configured. If the notification fails to appear, you will be able to test for a conflict quickly instead of rewriting the condition itself.

Installation and the First Post-Activation Check

Installing a premium add-on in the GamiPress ecosystem works like a standard ZIP plugin upload in WordPress. The official pro add-ons guide describes the path through Plugins > Add New, the plugin upload button, selecting the ZIP file, and activating it. This guide does not cover purchasing, license keys, or any license workarounds. Its purpose is to help you configure functionality for a product you already have.

What to do right after installation

1. Verify that the main GamiPress plugin is active and that the admin menu contains the GamiPress section.
2. Confirm that the Notifications add-on is installed and that its settings are available under GamiPress > Settings > Add-ons.
3. Activate GamiPress Conditional Notifications and make sure a Conditional Notifications menu item appears under GamiPress.
4. Open the conditional notifications list. The documentation describes it as a screen that shows the title, status, and date for each notification.
5. Do not create a complicated rule yet. Start with a simple test: one condition, short text, active status, and a small display limit.

If the menu item does not appear, do not rush to reinstall the add-on. Check the permissions of the current user, confirm that the main GamiPress plugin is active, and verify the dependent Notifications add-on. If the admin area is showing JavaScript errors, the condition dropdowns may not work correctly, and it may help to temporarily disable unnecessary admin-side extensions.

A quick interface check

Open the create or edit screen for a conditional notification. You should see blocks for notification configuration, style and sounds, conditions, and publishing details. One important sign that everything is working correctly is that changing the condition also changes the set of additional fields. For example, when you choose a points threshold, fields related to point amount and point type should appear. If the interface does not react, the issue is usually an admin-side script conflict or an incomplete dependency installation.

Settings Map: From Notification Text to Display Limits

The main editing screen works best when you think of it as a sequence of decisions. First, decide what the user should see. Then decide how it should look. After that, choose the condition that triggers it. Finally, decide whether the rule is active, when it should start working, and how many times it can be shown. This order helps you keep the message aligned with the event.

Notification Configuration: purpose and message

The configuration block defines the notification title and content. The title acts as the short reason the message appeared. The content explains the next step. Weak copy says only "congratulations." Strong copy explains what happened, why it matters, and what the user can do next: view a new section, continue a task series, open the rewards page, or check their balance.

Do not make your first notification too long. A live site message is read quickly, often in between actions. The ideal text contains one clear idea and one next step. If the user needs detailed instructions, it is better to link to a page or achievement rather than overload the popup itself.

Notification Style & Sound Effects: local styling without clashing with global settings

The documentation explains that this block lets you configure color and sound effects for a specific conditional notification, while empty fields inherit values from the Notifications add-on settings. That is a convenient and safe model: global settings define the baseline appearance, while an individual condition overrides only what truly needs to be different.

For a typical site, it makes sense to start with the global settings: position, width, auto-hide, delay, colors, text size, border, and radius. A separate style is more useful for important milestones such as reaching a rank, completing all achievements of a type, or hitting a major points threshold. If every notification looks like a special event, users quickly stop distinguishing the messages that actually matter.

Condition Configuration: the trigger point

The condition is the most important field. The documentation lists five main options: Reach a points balance, Unlock a specific achievement, Unlock any achievement of type, Unlock all achievements of type, and Reach a specific rank. Once you choose a condition, additional fields appear to define the relevant point type, achievement, achievement type, or rank.

The right choice depends on your goal. If the notification should motivate the user after a particular reward, choose a specific achievement. If you want to support an entire category, such as quests or course badges, choose an achievement type. If the message should appear only after the full set is complete, use the all-achievements-of-type option. A points threshold works well for loyalty scenarios, while rank is better for level-based progress.

How to avoid choosing the wrong condition

The most common logic mistake is choosing a condition that is too broad. For example, "any achievement of type" will fire much more often than "a specific achievement." That is not a bug. It is simply the result of your selection. Before saving the rule, say the condition out loud in plain language: "Show this notification when the user unlocks any achievement of type Quest." If that statement sounds too broad, the rule needs to be narrowed.

Details: status, date, and Maximum Displays

The details block controls notification availability. The status must be active, or the notification will never appear. The date matters because the first notification will only be shown after the selected date. The Maximum Displays field limits how many times it can appear, and a value of 0 means there is no maximum. For testing, it is useful to set a low limit so you can quickly tell whether the message repeats too often.

A safe starting point: create the notification in an inactive state, fill in the text and condition, and only activate it right before testing. If the result is not right, switch it back to inactive and adjust the rule without deleting it.

How to Choose a Condition So the Notification Does Not Turn Into Noise

GamiPress Conditional Notifications offers only a few core conditions, but the condition you choose is what determines the quality of the result. Administrators often focus on the notification text, color, and effect, but make the real mistake elsewhere: they choose an event that is too broad or realize too late that one message will appear in several different user situations. That is why it is better to choose the condition from the scenario, not from the dropdown.

A workable scenario starts with one question: what exact moment should the user notice? If the answer is "they earned a specific reward," you should use a specific achievement. If the answer is "they advanced within a category of tasks," an achievement type may be the right fit. If the key moment is about a total, use a points balance. If it is about the user's status in the system, use a rank. That way, one notification is not forced to explain several unrelated events at once.

Points threshold: when the total matters more than the individual action

The Reach a points balance condition is useful when the user needs to notice an accumulated result. That could be a threshold for a reward, access to the next content block, an internal club currency, or an activity benchmark. The important detail is that the event here is not a specific points award, but the moment the balance is reached. If points can be earned in many different ways, the notification should still explain the threshold itself, not every action that contributed to it.

Before launching a rule like this, check how many users are already above the threshold. If the site has been running for a while, older users may already have the required balance before the notification is created. In that case, test with a new account or temporarily use a separate threshold. For production, keep the wording neutral: not "you just reached this for the first time" unless you are certain about the history, but something like "your balance has reached the level where the next step is now available."

A specific achievement: when the message needs to be exact

Unlock a specific achievement is the clearest option for learning flows and content challenges. The user earned a specific badge, completed a specific module, or met a specific requirement. The notification can be precise: what was completed, what is unlocked next, and where to check progress. This type of scenario feels the least like spam because the message is clearly tied to the event.

The weak point of this approach is scale. If you have many achievements and each one requires its own notification, administration becomes heavy very quickly. In that case, decide which achievements truly need custom messaging and which ones can remain at the basic GamiPress Notifications level. Not every reward needs its own guided prompt.

Any achievement of a type: when the category is what matters

Unlock any achievement of type works well when all achievements within a type carry similar meaning. For example, you may have a "course quests" type, and each unlocked achievement in that type should remind the user about the next lesson. But if that type mixes different kinds of entities, such as educational badges, social rewards, and technical markers, one notification will become too generic.

Before choosing this condition, open the list of achievements in the selected type and check whether one message can honestly fit every one of them. If the text becomes vague, it is better to narrow the condition to a specific achievement or split the achievements into clearer types.

All achievements of a type: when you need to mark the completion of a series

Unlock all achievements of type works best as a final signal. The user has collected every reward in a category, completed a content series, or finished a task set. Here the notification can carry a little more weight: it can suggest the next section, a summary page, a leaderboard, or a new category. But it should appear rarely, or the sense of completion disappears.

For this condition, progress validation matters even more. If achievements are awarded retroactively, manually, or through integrations, test the full path: unlock part of the set, then the final one, then verify that the notification appears on the actual last step. If it appears too early, check whether the type includes test or hidden achievements that change the logic of "all achievements."

Rank: when the notification is tied to status

Reach a specific rank is a strong fit for sites where ranks are understood as levels, status markers, or development stages. The message should explain the meaning of the new rank, not simply congratulate the user. If the new rank unlocks access, that must be backed by actual access rules rather than just promised in the notification. If the rank is purely symbolic, present it honestly as a progress marker.

For ranks, it helps to keep a consistent tone: a brief acknowledgment of the result, a clear explanation of what changed, and the next milestone to aim for. Do not make every rank notification feel too dramatic. Users should feel that the system is helping them move forward, not distracting them from what they came to do.

Global Notifications Add-On Settings That Affect Conditional Notifications

Conditional Notifications lets you configure separate rules, but the live delivery and baseline appearance come from the Notifications add-on. That means some problems are not solved inside the conditional notification itself, but in the general notification settings. If you skip that layer, you may spend a long time editing a specific rule while the real cause lies in the block position, auto-hide behavior, width, sound, or live checks.

The official Notifications add-on documentation describes these settings under GamiPress > Settings > Add-ons. There you define position, user notification retention, live checks on or off, click behavior, auto-hide, auto-hide delay, show and hide sounds, width, colors, text sizes, border, and parameters for individual notification types. For Conditional Notifications, the most important items are the ones that control how the block behaves on the page.

Position and width

The notification position should fit the site's interface. If your site has a sticky header, chat widget, consent banner, or floating cart, placing the notification in the same corner may cover important elements. Start with the corner that has the fewest interactive elements and test it on several page types: a regular post, an account page, a page with a form, and a mobile-width view.

Width affects readability. The Notifications add-on documentation suggests a recommended range between 300 and 600 pixels and notes that the width adapts on mobile screens. In practice, that means your message should not be longer than a compact block can handle. If the notification requires two or three full sentences, it may no longer be a notification at all, but a cue to send the user to a separate page with the full explanation.

Auto-hide and click to hide

Auto-hide is convenient for short messages, but risky for important instructions. If the notification contains an action the user actually needs to read, the delay should feel comfortable. A simple "balance reached" message can use a short duration, while "the next stage is unlocked, go to the tasks section" usually deserves more time or a click-to-hide option.

Click to hide is helpful when the notification should not get in the way. But if the page has many clickable elements nearby, test whether the user might dismiss it accidentally. Ideally, the user should have enough time to read the message and decide whether to close it or follow the link.

Sound and visual emphasis

Sound can reinforce an important event, but it quickly becomes irritating on a site with frequent rewards. For an initial rollout, it is usually better to disable sound or reserve it only for rare events: a new rank, a full set of achievements, or a major points threshold. If every small action makes a sound, users may begin to experience the gamification layer as an interruption.

Colors and text size should support the theme without blending into it. If a notification looks like a system error, users will react with unnecessary concern. If it looks like an ad banner, they will start ignoring it. The best approach is a calm style that fits the site's interface, plus one visible accent for truly important achievements.

Live checks as a balance between immediacy and server load

The Disable live checks setting deserves its own decision. The documentation states plainly that enabling it disables the live notification feature, but lowers resource usage. For an active community, immediacy matters because the user sees the response right after the action. For a high-traffic site or a site with many events, more careful testing may be needed to understand how much live checks affect performance.

Do not enable or disable live checks blindly. First, run one controlled scenario with live checks enabled, then evaluate the load and the user experience. If the administrator decides to disable live checks for performance reasons, that decision should be documented for the site: Conditional Notifications should no longer be treated as an instant-response layer.

Personalization Through Tags and Shortcodes

Conditional Notifications becomes much more useful when the message shows actual user or reward data instead of generic text. The official available tags page confirms several important rules: tags work in both the title and the content, the notification content executes shortcodes, and tags related to GamiPress types are added automatically based on the type slug.

That gives you flexibility, but it also requires discipline. The tag must be recognized by the system, and the shortcode must make sense inside a compact notification. If you insert a heavy output block or a complex achievement card, the notification can become oversized and awkward on mobile screens.

How to use tags without overloading the message

Start with one or two dynamic elements. For example, keep the title in plain human language and use the content to show the balance or achievement title. Do not try to output the entire user profile, reward log, and a list of links in one notification. A live message should stay short, while details can point to the rewards page, account area, or a full instructional guide.

Shortcodes inside notifications

The documentation gives an example of using a tag as a shortcode attribute value: [gamipress_achievement id="{quest_id}" user_id="{user_id}"]. That is a powerful option because the notification can display a fragment tied to a specific achievement. But it should only be used when the shortcode produces a compact result that fits the notification visually and structurally.

Before going live, test the shortcode on a normal page first. If it outputs a large block, images, a long description, or UI elements that do not fit well inside a notification, it is better to keep the notification limited to a link or a short message. First validate the shortcode output on its own, then move it into the conditional notification.

Type slugs and the risk of renaming them

Tags for GamiPress types are built from the slug. The documentation shows an example: a points type with the slug gems can have a tag such as {gems_balance}, while an achievement type like badges produces tags such as {badges_id}, {badges_title}, and {badges_link}. If you rename a type or change its slug in a live project, make sure to review every notification that depends on those tags.

For a stable site, it is better to settle on clear slugs early and avoid changing them unless there is a strong reason. If you do need to change one, make a list of the notifications that use the related tags and test each rule with a test user.

Practical Example: A Notification After Reaching a Points Balance

Let us walk through a scenario that works well for a learning site, a membership club, or a loyalty-based store. The goal is to show the user a message when they reach a target points balance. The message should do more than congratulate them. It should point to the next step, such as opening the rewards page or continuing toward the next rank.

Goal

The user earns the required number of points and immediately sees a notification. The message has a clear purpose: "your balance has reached the threshold, and the next step is now available." That helps preserve the motivational moment the reward system was meant to create.

Preparation

Before setting this up, make sure the point type already exists, that the test user can earn points through a GamiPress event, and that the Notifications add-on is already displaying standard notifications. If the basic reward notification is not working, do not test Conditional Notifications yet. Fix the general notification layer first.

Configuration steps

1. Open GamiPress > Conditional Notifications and create a new conditional notification.
2. In the title, enter a short phrase such as "Balance Reached" or "Next Step Unlocked."
3. In the content, add a specific action: go to rewards, view progress, or continue the task.
4. In the conditions block, choose Reach a points balance.
5. Specify the point type and the threshold that must be reached.
6. Leave the custom colors blank if you want to use the global Notifications add-on style, or add a separate accent for this important event.
7. Set the notification to active and choose a reasonable Maximum Displays value so the message does not become intrusive.
8. Save the notification and move on to testing with a separate user account.

Verification

While logged in as the test user, perform the action that awards the required points. Once the threshold is reached, the notification should appear on the site, and its text should match the selected condition. Do not check only whether it appears. Also check whether the message makes sense: is it clear why the user saw it, where they should go next, and whether it looks like a useful prompt rather than a system error?

A nuance with an already reached balance

If the test user already had the required balance before the rule was activated, the result may not be obvious. For a clean test, use a user whose balance is below the threshold or temporarily set a new threshold that can be reached through one clear action. After testing, switch it back to the production value.

Example takeaway: the condition controls the trigger moment, the text gives the message meaning, the display limit shows respect for the user, and the test account proves the rule works outside the admin panel.

Practical Use Ideas for Different Types of Sites

Conditional notifications should not look the same across every project. The same mechanism can be used as a learning prompt, a progress signal, a motivation aid, or a subtle navigation cue. Below are several scenarios built around confirmed GamiPress conditions: points, achievements, achievement types, and ranks.

Online course: a prompt after an important badge

If the course uses achievements for module completion, configure a notification for Unlock a specific achievement. The message can explain that the student has completed a key stage and should now move to the next module or practical assignment. The test is simple: the student account earns the achievement and sees a message with a clear next step.

Community: a message after moving to a rank

For a forum, club, or private community, Reach a specific rank is often the better fit. The notification can explain which capabilities or expectations are tied to the new level. Do not promise automatic access to features unless that access is actually controlled by a separate plugin or rule. Only describe what truly exists on the site.

Store or loyalty program: a points threshold

If GamiPress is awarding points for actions or purchases through supported integrations, a balance-based notification helps you prompt the user at the right moment, just as they are getting close to or reaching a reward. Display limits matter especially here: a threshold message should not appear after every future points award once the user already understands what happened.

Content project: completing an achievement series

The Unlock all achievements of type condition works well for a content series, challenge, or task set. The user is not just seeing one more reward, but the completion of a full block. The message should state that the series is complete and offer the next logical route: a new section, a leaderboard, a profile page, or another task set.

How to Verify the Result on the Site and in the Admin Panel

A successful setup is more than a saved item in the Conditional Notifications list. Functionality should be checked from both sides: in the admin panel, the rule should be active and attached to the correct condition, and on the frontend, the user should see the notification at the expected moment. This two-sided verification matters especially on sites with caching, multiple point types, and a large number of achievements.

Admin-side verification

• In the conditional notifications list, check the title, status, and date.
• Open the item and make sure the condition is not too broad and was not selected by mistake.
• Review Maximum Displays; for testing, you should clearly understand how many times the notification is allowed to appear.
• Compare the individual styles against the global Notifications add-on settings if the appearance looks different from what you expected.

User-side verification

Log in as a test user, perform the action that should lead to the condition, and watch for the notification on the page without the admin panel open. If the event is tied to points or an achievement, also check the GamiPress log or the user's related screens to confirm that the reward itself was actually granted.

It is worth repeating the test in several environments: a normal browser, incognito mode, a mobile-width screen, and a page without a heavy page builder. This helps separate a rule problem from a theme or page-specific issue. If the notification appears on a simple page but not on a builder-based page, look for a conflict in the frontend scripts, optimization stack, or template.

How to tell whether the setup will hurt the user experience

Look at the notification through the user's eyes. It should not cover an important button, interfere with a form, trigger an overly sharp sound, or appear too often. The Notifications add-on includes settings for position, auto-hide, delay, width, colors, text size, and border. Use those as your general quality-control layer, and reserve individual styles for truly important events only.

Compatibility, Performance, and Careful Live Check Configuration

The official Notifications add-on documentation is explicit about the Disable live checks setting: enabling it completely disables the live notification feature, but it may significantly reduce server resource usage. For Conditional Notifications, this is a critical parameter. If live checks are off, you should not expect notifications to appear in real time.

There is no universal answer that fits every site. A small membership club with moderate activity may leave live checks enabled. A high-traffic site with many events and strict performance requirements should test load more carefully. In any case, the decision should come after validation, not from a reflex to "turn everything on because it looks better."

Page caching

Caching is usually necessary for a site, but personalized notifications depend on the current user. If the page is served entirely from cache without accounting for authentication, user-specific elements may behave unpredictably. Do not assume in advance that caching is the problem, but keep it on your checklist: exceptions for logged-in users, JavaScript settings, deferred loading, and script combining.

Themes and page builders

GamiPress claims compatibility with modern WordPress themes, but real output always depends on the theme and plugin stack in use. If the notification is visually broken, start with the global width and color settings, then follow the official conflict-testing workflow: temporarily switch to a default theme and disable extra plugins, leaving only GamiPress and the required add-ons active.

Multisite and roles

GamiPress supports WordPress multisite and can centralize data when network-activated. But with Conditional Notifications, do not draw conclusions without testing your exact setup. On multisite, verify where GamiPress, Notifications, and Conditional Notifications are activated, where points are stored, and on which site the user performs the action. If subsite administrators cannot see the necessary menus, check permissions and the network configuration.

Safe Improvements Without Editing Plugin Code

For this add-on, it is wiser not to start with PHP snippets. The available documentation confirms settings, tags, and shortcode execution in notification content, but there is no need to invent hooks or modify code. The safest improvements here come from stronger message writing, better global styling, careful shortcode use, and compatibility testing.

Improve the message as part of the interface

Build each notification around a short formula: event, meaning for the user, next step. For example: "You completed all achievements in this section. Open the final task in your account." That is much more helpful than an abstract "Congratulations!" It reduces confusion and turns the notification into part of the site's navigation.

Use the global style as your foundation

Set the shared position, width, auto-hide behavior, and core colors in the Notifications add-on. Then use Conditional Notifications to override only the truly important events. This is easier to maintain: if the site changes its theme or color scheme, you will not have to update dozens of individual notifications.

How to roll back a questionable change

If a change makes the notification worse, do not delete the entry right away. Switch it to inactive, clear the individual styles, restore the shared Notifications add-on style, and rerun the test with one condition. This rollback preserves the text and rule logic while removing the effect of questionable styling.

Why the Notification Does Not Appear or Fires Incorrectly

It is best to troubleshoot this in a chain: dependency, condition, event, status, limit, live output, then theme or cache conflict. If you begin by reinstalling the add-on, you may waste time and miss a simple cause: the rule is inactive, the test user already met the condition, live checks are disabled, or the selected event is too broad.

The notification does not appear after the expected action

Symptom: the user completed the action, but no popup message appeared. First, check whether points were awarded, the achievement was unlocked, or the rank changed. If the underlying GamiPress event never happened, the conditional notification has nothing to respond to.

Then verify the notification's active status, date, and Maximum Displays. If the limit has already been exhausted for the test user, the rule may look fine in the admin panel but never appear again. After that, check the Notifications add-on and the Disable live checks setting. If live checks are disabled, live notification output will not work.

The wrong notification appears

Symptom: the user gets a message, but it relates to the wrong achievement or appears too often. The likely cause is an overly broad condition. For example, you selected "any achievement of type" when you actually needed a specific badge. Open the rule and say the condition in plain language. If it sounds broader than your real goal, narrow it.

Tags are not being replaced in the message

Symptom: the user sees curly braces or a blank space instead of a value. Check the GamiPress type slug and confirm that the needed data is available for the selected condition. Type-related tags are built from the slug, so if the slug is different from what you expected, the tag will not match. For shortcodes, validate the output on a regular page before placing it inside the notification.

The notification style is broken on the frontend

Symptom: the notification appears, but it overlaps the interface, has the wrong width, uses poor colors, or does not hide properly. First, clear the individual styles so the rule falls back to the global Notifications add-on settings. Then check width, auto-hide behavior, delay, text color, and position. If the issue only appears with one theme or on one builder page, run a conflict test by temporarily switching themes and disabling extra plugins.

The notification keeps repeating and annoys users

Symptom: the same message appears more often than it should. Check Maximum Displays, the condition, and the logic of repeated achievement. If the condition is tied to a points balance, think about whether the user should really see the message after every future points award. In many cases, it is better to limit the displays and make the wording more precise: not "you earned a lot of points," but "you have reached the threshold for the next step for the first time."

Condition dropdowns or fields do not work

Symptom: selectors do not open in the admin panel, extra fields do not appear after choosing a condition, or the edit screen behaves inconsistently. Check the browser for JavaScript errors and run the official conflict test: a default theme, temporary deactivation of third-party plugins, and only GamiPress plus the required add-ons left active. If the problem disappears, re-enable the plugins one by one and repeat the action that caused the interface to break.

When GamiPress Conditional Notifications Is the Right Choice

This add-on is worth using when the site already has a meaningful GamiPress system and you need to speak to the user at exactly the right moment. It works especially well for points thresholds, specific achievements, completion of an achievement set, and rank transitions. When configured well, the notification becomes part of the user's path: it explains progress, points to the next step, and does not overload the interface.

Before launching it on a live site, verify three things: the core Notifications add-on is working, the GamiPress condition fires correctly, and the notification does not clash with the theme, cache, or mobile interface. If those checks pass, you can download the installation package, install it in a test environment, and move it to the production site only after a controlled validation scenario.

If you need email, a BuddyBoss social feed, or full automation across dozens of plugins, choose a different tool that fits that channel. But if the job is "show the user an exact message after an important GamiPress event," Conditional Notifications handles it directly and without unnecessary complexity.