Forum Replies Created

Viewing 15 replies - 1 through 15 (of 796 total)
  • Hi there,

    In WordPress Multisite, users are shared across all sites, so the same email can’t register twice. To let a user access site2 after registering on site1, you just need to add the existing user to site2:

    1. Go to your Network Admin dashboard.
    2. Click Sites, then edit site2.
    3. Go to the Users tab.
    4. Add the user by entering their email or username and assign a role.
    5. Alternatively, from site2’s dashboard, go to Users > Add Existing User and add them there.

    This way, the user can log in once and access both sites. For more details, see the guide on managing users in multisite: https://docs.wpvip.com/manage-user-access/wordpress/

    Give it a try, and let me know how that goes!

    Hi @learningwp123,

    Glad I could help! If you encounter any other issues with your WordPress site in the future, please consider opening a new ticket in the support forums. The community there is very helpful and can assist you further.

    Good luck, and feel free to reach out if you need anything else!

    Best,
    Faisal

    Hi there,

    It sounds like you don’t have administrator access privileges. If you’re using GoDaddy, please open a support ticket via the following URL so they can review and resolve the issue.

    In the meantime, if you have multiple accounts, you can log in to check if any of them have administrator privileges.

    https://www.godaddy.com/en-in/help/contact-us

    Thank you

    Faisal Ahammad

    (@faisalahammad)

    Hi there,

    I tried to reproduce the issue but was unable to do so on my side. Could you please share your webpage URL so I can check and try to find a solution?

    Regards
    Faisal (volunteer)

    Faisal Ahammad

    (@faisalahammad)

    Hi there,

    I tried to reproduce the issue on a local WordPress test site with a hierarchical custom taxonomy in the block editor, but I was not able to replicate the panel height problem on my side.

    A couple of things would be useful to confirm first:

    • Are you using the latest version of Ninja Forms v3.14.2?
    • Have you tested with a default WordPress theme such as Twenty Twenty-Five to rule out a theme-side editor style conflict?

    If you are still seeing the issue, you can try this temporary workaround as an MU plugin.

    <?php
    /**
     * Plugin Name: NF Taxonomy Panel Workaround
     * Description: Temporary block editor CSS workaround for hierarchical taxonomy sidebar height.
     */
    
    add_action( 'admin_head-post.php', 'nf_fix_taxonomy_panel_height' );
    add_action( 'admin_head-post-new.php', 'nf_fix_taxonomy_panel_height' );
    
    function nf_fix_taxonomy_panel_height() {
        $screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
    
        if ( ! $screen || ! method_exists( $screen, 'is_block_editor' ) || ! $screen->is_block_editor() ) {
            return;
        }
        ?>
        <style id="nf-taxonomy-panel-height-workaround">
            .editor-post-taxonomies__hierarchical-terms-list,
            .editor-post-taxonomies__terms-list,
            .editor-post-taxonomies__hierarchical-terms-list.components-flex,
            .editor-post-taxonomies__terms-list.components-flex {
                height: auto !important;
                min-height: 0 !important;
            }
        </style>
        <?php
    }

    To use it as an MU plugin:

    1. Go to your WordPress site files.
    2. Open wp-content/mu-plugins/
    3. If the mu-plugins folder does not exist, create it.
    4. Create a new file named nf-taxonomy-panel-workaround.php
    5. Paste the code above into that file.
    6. Save the file and refresh the block editor.

    MU plugins load automatically, so you do not need to activate it from wp-admin.

    Just to be clear, I am not part of the Ninja Forms team. I am only helping here as a volunteer. Because of that, if this snippet does not help, the Ninja Forms team may not be able to assist further with custom workaround code since that is usually outside their normal support scope.

    Give it a try, and let me know how that goes!

    Best regards,
    Faisal (volunteer)

    • This reply was modified 2 months ago by Faisal Ahammad. Reason: Screenshot attached
    Faisal Ahammad

    (@faisalahammad)

    Hi @helgatheviking,

    I reviewed the behavior and the issue does look related to how the Ninja Forms Views rate limiter handles logged-in users in the block editor.

    At the moment, the plugin appears to apply its Views API rate limiting to non-admin users even when they already have permission to access submissions. On some sites, that can cause 429 Too Many Requests errors in the block editor for Editor users or other non-admin roles. A temporary workaround is to raise the rate limit only for logged-in users who already have the same Ninja Forms submissions/view capability configured on the site.

    If you want to try that, you can add the following as a small MU plugin:

    <?php
    /**
    * Plugin Name: Ninja Forms Views Rate Limit Workaround
    * Description: Prevents authorized non-admin users from hitting Ninja Forms Views rate limits in the block editor.
    */

    defined( 'ABSPATH' ) || exit;

    add_filter( 'ninja_forms_views_rate_limit', function( $limit, $endpoint ) {
    if ( ! is_user_logged_in() ) {
    return $limit;
    }

    $views_capability = apply_filters(
    'ninja_forms_views_token_capability',
    apply_filters( 'ninja_forms_admin_submissions_capabilities', 'manage_options' )
    );

    if ( current_user_can( $views_capability ) ) {
    return 1000;
    }

    return $limit;
    }, 10, 2 );

    You can install it like this:

    1. Create this file:
      /wp-content/mu-plugins/nf-views-rate-limit-workaround.php
    2. Paste the code above into that file.
    3. If the mu-plugins folder does not already exist, create it first.
    4. Save the file and test again with the affected Editor user.

    This workaround does not disable rate limiting for everyone. It only increases the limit for logged-in users who already have permission to access the Ninja Forms Views/submissions endpoints, so public or unauthorized traffic will still use the normal rate limit.

    Just to set expectations clearly, I am not part of the Ninja Forms team. I am helping here as a volunteer. Because of that, if this custom code does not work in your specific setup, the official Ninja Forms support team may not be able to troubleshoot or support it, since custom snippets are usually outside their support scope.

    That said, based on the code path involved, this looks like a reasonable and low-risk workaround until the plugin itself is updated.

    Best regards,
    Faisal (volunteer)

    Faisal Ahammad

    (@faisalahammad)

    Hi @emielb,

    You can try the old version to see if that helps. If you are looking for help from the Ninja Forms team, you can contact their support directly through their website here: https://ninjaforms.com/contact/

    Best regards,
    Faisal (Volunteer)

    Faisal Ahammad

    (@faisalahammad)

    Hi there,

    Could you please share your webpage URL so I can provide you with personalized CSS code to achieve this?

    Regards
    Faisal (Volunteer)

    Hi there,

    You’ll need their User Management plugin to grant the following access privileges to your Editor user. However, if you’re looking to assign specific access or roles to an individual user, it is not possible. I tried some custom code before but had no luck.

    Hi again,

    It looks like they still exist, and you may be able to get support or extend your support (possibly) from CodeCanyon using the following URL. Since this is beyond our scope, we’re unable to assist here.

    https://codecanyon.net/item/jobsearch-wp-job-board-wordpress-plugin/21066856

    Thank you

    Hi there,

    Could you please confirm which WP Job Search plugin you are using? Have you tried contacting the plugin support to see if they can assist you? Unfortunately, we are unable to help with specific plugin issues in this forum.

    If the plugin is available in the ww.wp.xz.cn plugin repository, you should reach out to their support forum for better and more personalized assistance. Also, we cannot provide support for commercial plugins here. Thank you for your understanding.

    Hi there,

    Are you using Elementor Pop-up? If so, it may be conflicting with Google reCaptcha v3 when used with Ninja Forms. This issue needs to be resolved by Elementor.

    However, you can try adding the following PHP code as an MU-plugin or in your child theme’s functions.php file to fix it. Your code is good, but the following version is recommended.

    <?php
    /**
    * Fix Google reCaptcha v3 loading issue in Ninja Forms with Elementor Pro.
    */

    add_filter('ninja_forms_pre_enqueue_recaptcha_v3_js', 'nfele_enqueue_recaptcha_v3_js');

    function nfele_enqueue_recaptcha_v3_js()
    {
    $recaptcha_lang = Ninja_Forms()->get_setting('recaptcha_lang', 'en');
    $site_key = Ninja_Forms()->get_setting('recaptcha_site_key_3');

    wp_enqueue_script(
    'nf-google-recaptcha',
    'https://www.google.com/recaptcha/api.js?hl=' . $recaptcha_lang . '&render=' . $site_key,
    array('jquery'),
    '3.0',
    true
    );

    return true;
    }

    Give it a try, and let me know how that goes!

    Best regards,
    Faisal (forum volunteer)

    Faisal Ahammad

    (@faisalahammad)

    Hi @zodiac1978,

    After further research, I found a workaround. If you feel comfortable, you can use the following code snippet as a mu-plugin or add it to your child theme’s functions.php file. This will insert a <br> tag when you press Shift+Enter.

    <?php
    /**
    * Ninja Forms builder: Shift+Enter => <br>, Enter => default paragraph
    */
    add_action( 'admin_footer', function () {
    if ( ! is_admin() ) {
    return;
    }

    $page = isset( $_GET['page'] ) ? sanitize_key( wp_unslash( $_GET['page'] ) ) : '';
    if ( 'ninja-forms' !== $page ) {
    return;
    }
    ?>
    <script>
    (function (window, document, $) {
    'use strict';

    var BLOT_NAME = 'nf-soft-break';

    function ensureSoftBreakBlot(quill) {
    if (!quill) return false;
    if (quill.__nfSoftBreakReady) return true;
    if (typeof window.Quill === 'undefined') return false;

    var Embed = window.Quill.import('blots/embed');

    class NFSoftBreakBlot extends Embed {
    static blotName = BLOT_NAME;
    static tagName = 'BR';
    static value() { return ''; }
    }

    try {
    // Quill 2 often uses per-instance registries.
    if (quill.scroll && quill.scroll.registry && typeof quill.scroll.registry.register === 'function') {
    quill.scroll.registry.register(NFSoftBreakBlot);
    } else {
    window.Quill.register(NFSoftBreakBlot, true);
    }

    quill.__nfSoftBreakReady = !!(quill.scroll && quill.scroll.query && quill.scroll.query(BLOT_NAME));
    return quill.__nfSoftBreakReady;
    } catch (err) {
    console.error('NF soft break register failed:', err);
    quill.__nfSoftBreakReady = false;
    return false;
    }
    }

    function insertSoftBreak(quill) {
    var range = quill.getSelection(true);
    if (!range) return;

    if (range.length > 0) {
    quill.deleteText(range.index, range.length, window.Quill.sources.USER);
    }

    try {
    if (ensureSoftBreakBlot(quill)) {
    quill.insertEmbed(range.index, BLOT_NAME, '', window.Quill.sources.USER);
    quill.setSelection(range.index + 1, window.Quill.sources.SILENT);
    return;
    }
    } catch (err) {
    console.error('NF soft break insertEmbed failed:', err);
    }

    // Fallback
    quill.clipboard.dangerouslyPasteHTML(range.index, '<br>', window.Quill.sources.USER);
    quill.setSelection(range.index + 1, window.Quill.sources.SILENT);
    }

    function bindEditor(editorEl) {
    if (!editorEl || editorEl.__nfSoftBreakBound) return;

    var quill = editorEl.__quill || $(editorEl).closest('.setting').data('quill');
    if (!quill) return;

    editorEl.addEventListener('keydown', function (e) {
    if (!(e.key === 'Enter' && e.shiftKey)) return;

    // Skip code view (<>) mode
    var setting = $(editorEl).closest('.setting');
    if (setting.hasClass('code-view')) return;

    e.preventDefault();
    e.stopPropagation();
    insertSoftBreak(quill);
    }, true);

    editorEl.__nfSoftBreakBound = true;
    }

    function scanEditors() {
    $('.ql-editor').each(function () {
    bindEditor(this);
    });
    }

    $(scanEditors);

    var observer = new MutationObserver(function () {
    scanEditors();
    });
    observer.observe(document.body, { childList: true, subtree: true });

    if (window.Backbone && Backbone.Radio) {
    try {
    Backbone.Radio.channel('setting-type-rte').on('render:setting', function () {
    setTimeout(scanEditors, 0);
    setTimeout(scanEditors, 120);
    });
    } catch (e) {}
    }
    })(window, document, jQuery);
    </script>
    <?php
    } );

    Give it a try, and let me know how that goes! 😄

    Faisal Ahammad

    (@faisalahammad)

    Hi!

    I’m a forum volunteer, and I can reproduce this issue.

    What’s happening:

    • In Email Actions > Email Message, if you switch to Code mode and the editor is empty, choosing a Merge Tag may not insert anything.

    If you’re not technical:

    1. Don’t edit plugin files yourself.
    2. Share this thread with your developer/host and ask them to apply the “maintainer patch” below.
    3. Temporary workaround: add merge tags in Visual mode first, then switch to Code mode.

    I tested a patch locally and it resolves the issue in Code mode.

    Root cause:

    • Merge-tag insertion flow still prioritizes Quill (visual editor) when CodeMirror (code mode) is active.
    • In empty code mode, selected tags have no valid insertion target.

    Patch applied and tested:

    => assets/js/min/builder.js

    • In mergeTagsButtonClick, add a CodeMirror-first branch:
      • Detect .setting.code-view:visible + .CodeMirror
      • Insert { at CodeMirror cursor
      • Save merge state/caret
      • Set window.nfCurrentCodeMirrorInstance = cm
      • Clear window.nfCurrentQuillInstance = null
      • Show/focus #merge-tags-box search input
      • return to avoid falling into Quill path
    • In insertTag, change Quill guard:
      • from:
        if (window.nfCurrentQuillInstance) { ... }
      • to:
        if (window.nfCurrentQuillInstance && !window.nfCurrentCodeMirrorInstance) { ... }
    • Add CodeMirror insertion branch:
      • Use current cursor and nearest { token start
      • replaceRange(tag, startPos, cursorPos)
      • Restore focus/cursor
      • Clear window.nfCurrentCodeMirrorInstance

    Post-patch:

    • Clear browser cache + server/CDN cache
    • Hard refresh wp-admin
    • Retest in Email action code mode with empty content

    Result:

    • Merge tags insert correctly in both Visual and Code mode.
    Faisal Ahammad

    (@faisalahammad)

    Hi Sarah,

    I tried to replicate the issue. When I searched for “Ninja Forms,” it worked fine. However, when I searched for “Ninja Form” (without the “s” at the end), I was unable to find it. I believe the plugin development team will address this to make the plugin easier to find in the repository.

    Best regards,
    Faisal
    (Forum volunteer)

Viewing 15 replies - 1 through 15 (of 796 total)