Event Scheduler插件仅登录可用，移动端及部分设备报错求助

Let's break down what's going on here and fix your plugin problems step by step:

Root Cause Analysis #

That TypeError: cannot use 'in' operator to search for 'length' in You are not allowed to do this error is a dead giveaway. Here's the core issue:

• When you're not logged in (or when the plugin's permission check fails on mobile/other devices), the backend isn't returning the JSON event data your code expects. Instead, it's sending back a plain text message: "You are not allowed to do this".
• Your frontend code tries to treat this text as a JSON object (accessing jsonEvents.data, checking .length, etc.), which throws the type error because strings don't have those properties.

The "works only on your PC" problem ties into this too—you're probably logged in consistently on your main machine, while mobile/other laptops either aren't logged in or have session/cookie issues breaking the permission check.

Fixes to Implement #

1. Add Defensive Checks in the Frontend Code #

First, let's prevent the type error by validating the response before trying to process it. Update your AJAX call like this:

$.ajax({
    url: esc_token.ajaxurl,
    type: "POST",
    async: true, // Ditch async:false—it causes performance issues and browser quirks
    dataType: 'json', // Force jQuery to parse the response as JSON
    data: {
        action: "getevents",
        security: esc_token.security,
        eventGroup: jsonFile
    },
    success: function (jsonEvents) {
        // First, make sure we got a valid successful response
        if (!jsonEvents || !jsonEvents.success || !jsonEvents.data) {
            console.error('Event fetch failed:', jsonEvents?.message || 'Invalid response');
            return; // Stop execution if the data isn't what we expect
        }

        // Your original event processing logic goes here
        $.each(jsonEvents.data, function(i, item) {
            $.each(dates, function(j, item2) {
                if (dates[j] == jsonEvents.data[i]['date']) {
                    if ((jsonEvents.data[i]['time'] !== null || jsonEvents.data[i]['time'].length > 0) && 
                        (jsonEvents.data[i]['title'] !== null || jsonEvents.data[i]['title'].length > 0)) {
                        events.push(jsonEvents.data[i]);
                    }
                }
            });
        });

        var eventObject = new Object();
        eventObject.id = schedulerId;
        eventObject.events = events;
        escImportedEvents.push(eventObject);
    },
    error: function(xhr, status, err) {
        // Catch cases where the response isn't valid JSON (like the permission text)
        console.error('AJAX Request Error:', status, err);
    }
});

Key improvements here:

• Added dataType: 'json' to ensure jQuery parses responses correctly, and triggers the error callback if it gets plain text.
• Added checks to validate jsonEvents and jsonEvents.data exist before processing.
• Removed async: false—synchronous requests block the browser and can cause unexpected behavior on mobile devices.

2. Fix the Backend Permission Response #

The plugin's backend code (handling the getevents action) is returning plain text instead of JSON when the user isn't logged in. Update that PHP code to return a proper JSON error response:

add_action('wp_ajax_getevents', 'your_getevents_function');
// Uncomment below if you want non-logged-in users to access this action
// add_action('wp_ajax_nopriv_getevents', 'your_getevents_function');

function your_getevents_function() {
    // Check user permissions first
    if (!is_user_logged_in()) {
        // Send a JSON error instead of plain text
        wp_send_json_error(array(
            'message' => 'You are not allowed to do this'
        ), 403);
        exit;
    }

    // Your existing event fetching logic here...
    wp_send_json_success($event_data);
}

This way, even when the user isn't logged in, the frontend gets a JSON object with success: false instead of plain text, which our updated frontend code can handle gracefully.

3. Debug Cross-Device Issues #

For the mobile/other laptop failures:

• Check if those devices are logged in—if the plugin requires login, users need to be authenticated to fetch events.
• Verify that the esc_token.security nonce is being generated correctly across devices. Nonces can sometimes fail on mobile if there's a cookie issue.
• Use your browser's DevTools (Network tab) to inspect the getevents request on problematic devices. Look at the response content to confirm if it's the permission text or another error.

Final Notes #

Once you implement these fixes, the type error should disappear, and you'll have clearer debugging info for any remaining cross-device issues. The core problem was mismatched response formats between logged-in and non-logged-in states—fixing that will make the plugin behave consistently across all environments.

内容的提问来源于stack exchange，提问作者Andrew Dushkin