CodeCanyon myCRED Integration for eForm - WordPress Plugin

Guide to Configuring CodeCanyon myCRED Integration for eForm and Awarding Points for Forms

CodeCanyon myCRED Integration for eForm is not meant for building forms from scratch. Its job is to connect two tools that are already installed: eForm handles the form, quiz, or questionnaire, while myCRED awards the user points, deductions, or badges for the desired action. In this guide, we will walk through how to prepare the site, where to enable the myCRED hook, which reward rules to choose for a specific form, and how to verify the result without guesswork.

This article is intended for a WordPress site owner, webmaster, or editor who already understands the goal: motivate users to fill out a form, complete a survey, submit a quiz, or take an action inside a user portal. This is not a retelling of the product listing or purchase details. The main focus is practical setup, result verification, and troubleshooting cases where points do not appear.

This add-on is especially useful when a form is part of an engagement system: training, a private club, a contest, a knowledge base, a post-lesson questionnaire, a reward-based application, a quiz with points, or any workflow where the user needs to see progress. But it will not solve the problem on its own if the site has no clear points logic, myCRED is not active, or the form is not tied to a registered user.

How the Add-on Fits into the eForm and myCRED Setup

This product has a simple but important role: it adds eForm as an event source for myCRED. In a standard eForm setup, the user submits data, sees a success message, and the administrator sees the submission in the database. Once the add-on is connected, there is an extra layer: myCRED receives the event signal and can write a reward entry to the user's log, apply a limit, use a log template, and, if badges are configured, connect the form submission to the user's progress.

That leads to the main practical conclusion: do not look for problems in the form alone. If the form submits successfully but no points are added, the chain may still be broken in the myCRED hook, the settings of the specific form, the point type, the repeat limit, or the user conditions. It is better to configure this as a chain, not as a single checkbox.

What Happens After a Form Submission

The flow looks like this: the user opens the page with the form, fills in the fields, eForm accepts the submission, the add-on checks the reward settings, myCRED calculates the number of points, and creates a log entry. If a badge is involved, the system checks whether the requirement for the badge level has been met. On the public side of the site, the user may then see an updated balance, points history, achievements table, or badge, if those elements are displayed through myCRED shortcodes or the theme interface.

This sequence helps keep the layers separate. eForm is responsible for fields, validation, score calculation, and saving the submission. myCRED is responsible for point types, hooks, logs, badges, ranks, and displaying user progress. The add-on sits between them and passes the event along with the correct rule.

Why This Is Not a Typical Notification Integration

Form integrations are often treated as email delivery, writing to a table, or sending data to an external service. Here the goal is different: the form becomes an action inside a motivation system. That changes the setup process. You need to decide in advance exactly what the person is being rewarded for, whether the action can be repeated, whether the reward depends on the quiz result, whether points should be deducted for an incorrect attempt, and where the user will see the outcome.

Do not judge the integration by the "form submitted" message alone. Check three things: the submission appears in eForm, the log entry appears in myCRED, and the user's balance or badge changes the way you expected.

Who This Setup Is For, and When Another Option Makes More Sense

CodeCanyon myCRED Integration for eForm works best on sites where a form does more than collect a request. It triggers an action that has value for the user. If you already use eForm for quizzes, surveys, questionnaires, user portals, or advanced forms with mathematical elements, this add-on lets you turn those actions into part of a points program.

The typical reader of this guide is a WordPress site administrator who wants to reward form submissions without writing a custom integration. The goal is not just to "turn on points," but to make the system predictable: one user should not be able to farm rewards through endless submissions, different forms can award different amounts, and a bad configuration should not break submissions that are already working.

Good Use Cases

• An education site where a user earns points for completing a quiz or assessment form.
• A private community where questionnaires, surveys, and feedback are rewarded with internal currency.
• A marketing contest where eForm collects responses and myCRED shows the participant's progress.
• A site with a user account area where the user can see action history, balance, and badges.
• A project with multiple point types where different forms affect different point categories.

When the Add-on May Be Unnecessary

If all you need is a contact form that emails the administrator, adding myCRED creates an extra layer you do not need. It also does not replace a full loyalty program builder if you need complex rules built around many external events, user segments, and automations across multiple plugins. In those cases, it is better to map out the whole engagement system first and then decide whether the eForm + myCRED combination is enough.

You should also avoid installing the add-on directly on a live site without testing if your current version of eForm or myCRED differs significantly from the documented requirements. Integrations between plugins are sensitive to hook logic, submission storage, user roles, and dependency updates.

What to Check Before Installing It on a WordPress Site

Preparation matters here for a reason. This add-on has required dependencies, and the result is only visible when eForm, myCRED, and the user workflow all function together. So before installation, it is worth doing a short but focused review.

Dependencies and a Test Environment

The official add-on documentation states that it requires eForm WordPress Form Builder and myCRED. If either plugin is missing or disabled, the integration cannot do its job. Before installation, check not only that both plugins are present, but also that the site already has a working eForm form and that myCRED is correctly writing ordinary events to its log.

For a live site, the safest order is this: first make a backup, then create a test user, then build a separate test form, and then check the myCRED log. Do not start with an important form that is already collecting real requests. It is much easier to configure the integration on a copy of the form, confirm the result, and only then move the rule into production.

User Roles and Guest Mode

myCRED works with WordPress users. If the form is available to guests but points should only be awarded to registered users, decide in advance how anonymous submissions should be handled. In most cases, rewards work best when users are required to sign in, or when the site clearly explains that points will only be credited if the form is submitted from a logged-in account.

This is especially important for quizzes and contests. A guest may see a successful submission message, but myCRED may not be able to tie the event to the correct account in the way the administrator expects. An authenticated user is a much more reliable basis for checking balances, logs, and badges.

Caching, Optimization, and Form Pages

Forms that depend on user state are often sensitive to aggressive caching. If the form page is cached as a static page, the user may see stale state, old messages, or broken script loading. Before launch, test the form in normal mode, in a private window, and under a test account. If the site uses a cache plugin, exclude the form page or make sure submission handling and balance updates are not relying on outdated HTML.

This kind of prep saves time during troubleshooting. If the base form or the myCRED log does not work before the add-on is installed, the integration only adds one more variable.

Installation and First Validation Without Unnecessary Risk

The add-on should be installed like a normal WordPress plugin: upload the ZIP archive through Plugins, activate it, and then move on to the dependency settings. But it is more useful to think in terms of validation steps than button clicks. You should have three clear states: before installation, after activation, and after the first test submission.

Installation Order

1. Confirm that eForm and myCRED are active and that the test form submits without errors.
2. Create a backup or use a staging copy of the site.
3. Upload the add-on archive through Plugins and click Activate.
4. Open the myCRED settings and check whether the hook related to eForm submission is now available.
5. Open the target eForm form and find the myCRED rewards settings inside the form.
6. Save a minimal reward rule and submit the form as a test user.

At this stage, there is no need to configure a complex formula, multiple point types, and badges all at once. For the first check, a static reward for one form is enough. If the simple chain works, it will be much safer to make it more advanced afterward.

What Counts as a Successful First Check

A successful installation does not end with the WordPress message that says "plugin activated." The real confirmation is a new entry in the myCRED logs after form submission. Open the myCRED log, find the test user, and confirm that the entry is tied to the eForm action, contains the expected number of points, and uses understandable text in the log template. If the entry exists but the text is unclear, that is not a critical failure. It just means the log template should be improved.

If the entry does not appear, do not change everything at once. First confirm that the myCRED hook is enabled, then that awards are enabled in the form, then that the correct point type is selected, and only after that move on to limits and user conditions.

Initial Configuration: the myCRED Hook and Form Settings

This integration has two main control points. The first one is on the myCRED side, where you enable the hook and define global rules. The second is inside the specific eForm form, where you can enable rewards, choose the reward mode, and override the global behavior. If you configure only one side, the result will be incomplete.

Global Hook in myCRED

In myCRED, hooks usually define the system-wide response to an event. For eForm, that event is a form submission. In the hook settings, pay attention to limits, the log template, and how different point types are handled. The documentation mentions template tags that can make the log clearer, for example by including the user, form ID, or form title. The clearer the log is, the easier it will be to explain later why a reward did or did not appear.

If the site uses multiple point types, do not enable all of them automatically. For testing, choose one point type and confirm that it changes only after the intended form. Then you can expand the setup.

Settings Inside the eForm Form

Inside the eForm form is where the actual reward rule is enabled. According to the documentation, the add-on lets you override global settings for a specific form, choose the reward mode, and disable point types you do not need. This is useful if one form should provide a basic reward, another should award points based on score, and a third should not affect the balance at all.

A practical setup starts with a single rule: enable award points, choose a static value, save the form, submit it as a test user, and check the log. Only after that should you move on to score or a mathematical element.

What Not to Enable Right Away

Do not start with deductions, complex formulas, and multiple point types at the same time. If the result does not match expectations, it will be hard to tell which part of the rule caused it. A safe sequence is this: static reward, then repeat limits, then score, then mathematical element, then badges.

Which Reward Rules to Choose for Different Forms

One of the add-on's strengths is that it offers multiple ways to calculate a reward. This is more than just "give 10 points for a submission." Depending on the form, you can use a fixed value, the eForm score, or a value from a mathematical element. The right choice depends on what the form is measuring.

Static Point: a Simple Reward for the Action Itself

A static reward works well for a questionnaire, feedback form, application, participation confirmation, or any simple form where the fact of submitting matters more than the result. The user takes the action and receives a fixed reward. This is the easiest mode to test and explain.

For a first launch, this is the best mode. It shows that the hook works, the form passes the event correctly, the myCRED log creates an entry, and the balance changes. If static rewards do not work, there is no point in moving on to score-based rewards.

Score Obtained: Reward Depends on the Result

Score mode is useful for quizzes, tests, and forms where eForm calculates a result. For example, a user completes an assessment quiz, gets a score, and myCRED awards points based on that result. The add-on documentation also describes a multiplier that can multiply the score by a chosen value. That is useful if the raw score is too small or too large for your points system.

The important thing here is to agree on scale in advance. If myCRED is used across the site for many actions, the reward for a quiz should not accidentally devalue everything else. Check the possible score range and compare it with the site's standard rewards.

Mathematical Element: When the Form Itself Should Calculate the Reward

A mathematical element works well for more flexible scenarios: eForm calculates a value inside the form, and myCRED uses that value as the basis for the reward. For example, the form may take several answers, coefficients, or a final calculated field into account. This mode is powerful, but it requires careful validation because any mistake in the form formula immediately becomes a mistake in the reward.

For this mode, run several test submissions with different input values. Write down the expected outcome before each submission: what result eForm should produce, and how many points the user should receive. After submission, compare the eForm submission, the myCRED log, and the user's balance.

Limits and Logs: How to Keep a Form from Becoming an Endless Point Machine

Any reward for a form needs a limit. If a user can submit the same form over and over and earn points every time, the system quickly loses meaning. In the myCRED hook for eForm, the documentation describes Limits, Days Limit, Log template, and template tags. These are not secondary fields. They are protection against the wrong behavior.

How to Think About Limits

A limit answers one question: how many times, and over what period, can one user receive a reward for this event. For a one-time questionnaire, it makes sense to allow the reward only once. For a daily checklist or recurring task, a day-based limit may work better. For a quiz, you may allow repeat attempts, but reserve the reward for the best attempt only, if that logic is handled by your form and rules.

Do not choose a limit blindly. Describe the real user scenario: does the person complete the form once, once a day, after every lesson, or for every new assignment? Then configure the restriction to match that scenario and test two submissions in a row. The first should produce the expected result. The second should either award points again according to the rules or correctly withhold them.

Why the Log Template Matters

The myCRED log is the main diagnostic tool. If an entry looks like an unclear technical string, the administrator quickly loses context. A good template should explain which form triggered the reward and why. The documentation lists template tags related to the user, form ID, and form title. Use them carefully and include only what actually helps make sense of the history.

Practical minimum: the log should make it obvious which form triggered the reward, which user received the points, and which rule was applied. If that is not visible, improve the log template before expanding the setup.

Form-Level Overrides

A global hook is convenient for general rules, but real sites rarely have only one form. You may have a contest registration form, a test form, a feedback form, and an application form. If they all award the same reward, the logic becomes too blunt. That is why form settings matter: they let you enable or disable rewards exactly where they are needed and assign separate values.

A good practice is to keep a small rules table outside the admin panel: form name, reward type, limit, point type, expected outcome, and date of the last check. This is especially useful when multiple editors maintain the site.

Badges and the Public-Facing Result After Form Submission

Points are useful on their own, but in myCRED they are often used together with badges. The add-on documentation describes a scenario where an eForm submission can contribute to awarding a badge if the corresponding myCRED add-on is active and the badge level has been created. It is important to understand that a badge does not appear automatically just because a form was submitted. First, the badge system must be configured in myCRED, and then the eForm event must be included in the reward logic.

Where to Show the Result to the User

Once the reward is configured, it is worth thinking about public display. The user should be able to see that the action mattered. That may be a balance in the account area, a points history, a badges block, a leaderboard, or a dedicated message after the form is submitted. myCRED provides shortcodes for displaying balances, history, hook tables, leaderboards, and badges. The exact set depends on the theme and the site structure.

Do not overload the form page with every widget at once. For an initial scenario, one clear result is enough: for example, show the current balance near the form and the reward history in the user account area. If the user only sees the form message but not the profile changes, the motivational value is weaker.

A Safe CSS Tweak for the Table of Available Actions

If you display the myCRED hook table or a similar block with reward rules, you can improve readability with a small CSS adjustment. This does not change business logic, does not touch plugin core files, and is easy to roll back. The approach is based on the public selectors documented for the myCRED hook table. Add the code in Appearance -> Customize -> Additional CSS or in a child theme.

.mycred-hook-table {
  border-collapse: collapse;
  width: 100%;
  margin: 1.5rem 0;
}

.mycred-hook-table th,
.mycred-hook-table td {
  border: 1px solid #d9e1ea;
  padding: 0.75rem;
  vertical-align: top;
}

.mycred-hook-table th {
  background: #f5f8fb;
  font-weight: 700;
}

After adding the CSS, open the page in a private window and check the mobile view. If the table looks worse in your theme, remove the snippet from Additional CSS. This is an external presentation tweak, not a change to reward logic, so it is safer than a PHP snippet without confirmed hooks from the product itself.

Practical Scenario: Rewarding an Educational Quiz

Let us look at a realistic scenario that fits this setup well. Suppose the site has a training module. After a lesson, the user takes an eForm quiz, receives a score, and myCRED awards points for completion. The administrator needs the result to be clear, resistant to abuse through endless retries, and visible in the user's profile.

Goal and Preparation

The goal is to award points for a quiz submission and show the result in the myCRED log. Before configuration, you should already have a test user, an eForm form that calculates a score, an active myCRED setup, the eForm hook enabled, and a page where the user submits the form. If score has not been configured yet, first make sure eForm produces the correct result on its own without involving myCRED.

Setup Steps

1. Create or duplicate an eForm quiz form so you are not experimenting on the live form.
2. Configure the questions, score, or mathematical element inside eForm and run one submission without any myCRED reward.
3. Enable the hook related to eForm submission in myCRED and define a clear Log template.
4. In the form settings, enable awards and choose Score Obtained or Mathematical Element if the reward should depend on the result.
5. Set a multiplier only after you understand the score range.
6. Configure the limit so that repeat submissions behave according to the rules of the course.
7. Submit the form as a test user and compare the score, the myCRED log, and the final balance.

Expected Result and Validation

After submission, an eForm submission should appear, the myCRED log should contain an entry with a clear description, and the user's balance should change by the expected amount. If badges are enabled, also check whether badge level progress appears correctly. Do not rely on a single screen: the form, the log, and the user's profile should all tell the same story.

A Note About Repeat Attempts

The most common risk in this scenario is the repeat submission. If the course allows the quiz to be taken more than once, decide in advance whether points should be awarded for every attempt. If not, the limit should stop repeated rewards. If yes, the log should clearly show each attempt, otherwise neither the user nor the administrator will understand the points history.

Use Ideas: Where a Points-Driven Form Creates Real Value

This integration only makes sense when the reward supports actual user behavior. Below are a few scenarios where eForm and myCRED work together to build a clear workflow instead of just adding points for the sake of points.

Learning Tasks and Mini-Tests

For a course or knowledge base, a form can confirm that the user completed a task. Static Point works for a simple completion confirmation, Score Obtained for a test with correct answers, and Mathematical Element for more flexible calculations. Check not only the final points, but also whether the user understands what they were awarded for.

Feedback Form After an Action

If the site collects feedback after a webinar, purchase, lesson, or consultation, a reward can increase completion rates. In that case, a fixed reward with a strict limit is usually the better choice, so one user cannot submit the same questionnaire repeatedly just to farm points.

A Contest with Visible Participant Progress

For a contest, eForm can collect answers while myCRED shows progress through the balance, history, or leaderboard. This kind of setup requires a clean log and clear rules. If participants dispute the outcome, the administrator should be able to quickly find both the submission and the matching myCRED entry.

A Portal with Badges for User Actions

If the site already uses badges, eForm can become one of the actions that lead toward an achievement. For example, a user completes a profile questionnaire, passes a check, or submits a report. The key is to configure the badge level in advance and verify that the visible badge appears neither too early nor too late.

How to Verify the Result After a Test Submission

Validation should be repeatable. It is not enough to see the balance change once. You need to understand which input led to which result, what happens on a repeat submission, and how all of this appears to the user. This is especially important if the site uses multiple forms and multiple point types.

Mini Validation Protocol

1. Record the test user's balance before submission.
2. Open the form as that user, not as an administrator.
3. Submit the form using responses you already know in advance.
4. Check the submission in eForm.
5. Check the myCRED log and the log entry text.
6. Check the new balance and any public-facing block, if one exists.
7. Repeat the submission to test the limit.

If the result differs from what you expected, change only one parameter at a time. For example, disable the multiplier first, then verify the point type, then the limit. Changing multiple settings at once often hides the real cause.

What to Save for Future Support

After a successful setup, record the rule in a working note: form ID, form name, reward type, point type, limit, expected result, where the balance is displayed, and how to check the log. This is not bureaucracy. It saves time. A few months later, it is much easier to open a short note than to reconstruct why that specific form awards that specific reward.

Also save one reference submission example. It should include the user's responses, the expected score or calculated value, the final number of points, and the link to the log entry. This becomes especially useful after updates: you repeat the same input and quickly see whether the logic changed. If the result is different, it is easier to determine whether the change came from the eForm formula, multiplier, myCRED limit, point type, or the public-facing balance display.

If Points Are Not Being Awarded: Troubleshooting by Symptom

Integration problems often look the same on the surface: the form was submitted, but no points appeared. The causes, however, can be very different. Below is a practical troubleshooting flow that starts with basic checks and moves toward narrower settings.

The Form Submits, but There Is No Entry in the myCRED Log

Symptom: the user sees the eForm success message, the submission is saved, but no new entry appears in the myCRED log. Possible causes include the hook not being enabled in myCRED, awards being disabled in the form itself, or the event not being tied to the user.

Check the hook first, then the form settings, then the test user's authentication state. If the form is available to guests, repeat the test as a registered user. Start the fix with a simple static point reward so you can rule out errors in score mode or the mathematical element.

The Entry Exists, but the Points Are Wrong

Symptom: the log shows the event, but the number of points is too high, too low, or negative. The cause is usually the selected reward mode, the multiplier, the mathematical element, or deductions. Disable the complex calculations and test a static value first. Then restore the score or formula and compare the expected outcome with the eForm submission.

The First Submission Works, but a Repeat Submission Does Not Award Anything

This is not always an error. Check Limits and Days Limit. The rule may be intentionally blocking repeated rewards. If the scenario is supposed to allow a daily reward, verify the restriction period. If the form is intended to be one-time only, then this behavior is correct.

The Badge Does Not Appear After the Reward

Symptom: the points were awarded, but the badge is not displayed. Check whether the badges add-on is active in myCRED, whether the required badge level has been created, and whether the badges block is displayed on the user's page. The form reward and the badge display are separate parts of the system. If there is no public shortcode block or profile area, the user may not see the badge even if the logic itself is working correctly.

The Form Becomes Unstable After Enabling the Integration

If submission errors, freezes, or strange messages appear, temporarily disable the reward rule in the form but do not delete the submission. Then check the browser console, page caching, script optimization conflicts, and the form's behavior without the integration. If eForm itself works reliably, restore the myCRED settings one by one.

Quick Troubleshooting Table

Symptom	What to Check First	How to Fix It Safely
No log entry	The myCRED hook and awards in the form	Enable a minimal static reward and repeat the test
Points are incorrect	Reward mode, multiplier, mathematical element	Compare the eForm submission with the expected formula
Repeat submission does not award points	Limits and Days Limit	Match the limit to the real form scenario
Badge is not visible	The myCRED badges add-on and shortcode output	Check the badge level and the profile page

Limitations You Should Know About in Advance

The integration is useful, but it should not hide the architectural limits of the site. It depends on two major plugins, user roles, form settings, myCRED logic, and the current theme state. So do not promise users rewards until you have verified the full scenario with a test account.

Compatibility and Updates

Official sources confirm the dependency on eForm and myCRED. But exact compatibility with your version of WordPress, PHP, theme, and other plugins has to be tested locally. Commercial marketplace add-ons may be updated less frequently than the core plugins, so before updating a live setup, always test it on a copy of the site.

Complex Rules Are Better Documented

The more forms, point types, and badges you have, the greater the risk of forgetting why something works the way it does. Write the rules down in a separate document, especially if the site is maintained by a team. That note should include not only the values, but also the reasoning: why this limit was chosen, why score is used, and where the user sees the result.

When It Is Better Not to Overcomplicate Things

If the form only collects occasional requests and users do not return to a personal account area, a points system may be unnecessary. In that case, it is usually better to improve notifications, submission confirmation, and request handling. myCRED logic is strongest when the user comes back and can see their progress accumulate.

When CodeCanyon myCRED Integration for eForm Is the Right Choice

This add-on is worth using when the site already has eForm, myCRED is already working, and the form needs to become part of a motivation system. The strongest scenario is when the user submits a form, sees a clear result in points or badges, and the administrator can quickly verify the full chain through the submission and the myCRED log.

Before launching it on a live site, build a minimal test chain: one user, one form, one point type, a static reward, a clear log template, and a repeat-submission check. If that chain works, you can move on to score, mathematical elements, badges, and multiple forms. If you are ready to test the product on your own site, near the download block you can download the latest version of CodeCanyon myCRED Integration for eForm and test it first on a site copy or a separate form.

The main selection criterion is simple: the integration should support a real user workflow, not just add one more item to the admin panel. If you can clearly explain what action earns the user points, where the result is visible, and how the administrator verifies it in the log, the product will be a useful part of a WordPress site.