EricB50

Thanks for the help. That’s exactly what I was thinking.

Yes I don’t want them reverse engineered.

Do you just do a key exchange with your sever then pass the credentials over?

I can license them and then track their IP origins. Is that your solution?

Thanks again.

I’ve also been plagued by this problem. My workaround has been to save the post as a draft. Go into Posts->All then select Quick Edit. The categories appear there. Select one, save it, then publish it.

But it seems to be removed from the side bar. I also use a plugin that sends notices based on the category called “Email Subscribers” which could be impacting this functionality. Unsure.

Yes that looks correct. We switched from their Paypal Standard to their new Paypal extension and I noticed it broke your payment buttons. I also have a single page using the smart buttons and it’s doing the same thing so I had to go back to the Paypal Standard until I can sort out how to make it work together.

As a follow up this issue is related to WooCommerce Paypal plugin conflicting with your plugin.

There is a

Error: zoid destroyed all

In the console that is related to the Paypal SDK getting called twice. Then it removes the doc elements.

See https://github.com/Luehang/react-paypal-button-v2/issues/30

for a discussion. I’m not sure how to modify your plugin to make it compatible with the Paypal SDK running adjacent with other plugins also using the SDK. I had to abandon your plugin unfortunately. As I have a similar conflict problem with my own single page use of the PayPal SDK and woocommerce paypal plugin that I have to solve.

Thanks for help. It’s not clear to me where this should be defined. Should my constructor just call set_current_screen and set it to a value?

I have not seen an example with wp_list_table that does this either. I do have problems sometimes with trying to use wp_list_table with tabs and pagination. Perhaps I should be setting up current screens for each tab?

If you have any more information on this it would be appreciated. I’d love to get this sorted out for my plugins.

It appears to be site-wide as js and css files generate these kinds of errors for all the plugins and themes.

sudo /etc/init.d/apache2 restart

Shows no errors

I’ve added TypesConfig /etc/mime.types to top level apache2.conf (the conf/mime.types generated errors)

I’ve been chasing the problem on and off for about a week. The WP install didn’t change just apache2 and php8 upgraded and reinstalled, which immediately caused these problems (there is also a live copy running fine). But I’m not sure what to do. Nothing seems to be working.

• This reply was modified 2 years, 8 months ago by EricB50.

Ok I think I figured it out. I changed the sequence to:

admin hooks setup (admin_menu)

$this->loader->add_action( 'admin_menu', $plugin_admin, 'add_plugin_admin_menu' );

then in add_plugin_admin_menu I added the screen option method in that object but not using the loader:

add_action('load-' . $page_hook, array($this, 'load_user_list_table_screen_options'));

Then when the load is triggered it initializes the table object and screen options

public function load_user_table_screen_options() {
        $arguments = array(
            'label' => __('Items', 'plugin_manage_options'),
            'default' => 30,
            'option' => 'items_per_page'
        );
        add_screen_option('per_page', $arguments);

        // instantiate the Table
        $this->MT = new Plugin_Manage_Table($this->plugin_name, $this->plugin_version);       
    }

It’s still not totally clear to me what the difference is, but it is working.

Edit: of course applying the options isn’t working…. It appears there’s no user meta data being created.

• This reply was modified 3 years, 6 months ago by EricB50.
• This reply was modified 3 years, 6 months ago by EricB50.

I’ve tried to move a few things around but I don’t know exactly what WP is doing. I’ll try to sum it up based on how the WP boilerplate starts up and how I tried to append new code for the wp_list_table object.

Here’s the sequence:

plugin.php -> Setup up instance of class-plugin-manage

class plugin-manage:

        $this->load_dependencies();  // has all require_once
        $this->set_locale(); // i18n object
        $this->define_admin_hooks(); // sets up admin side
        $this->define_public_hooks(); // sets up public side

The hooks for admin are setup like this using the loader object:

private function define_admin_hooks() {
        $plugin_admin = new Plugin_Name_Manage_Admin($this->get_plugin_name(), $this->get_version(), $this->get_loader());
        $this->loader->add_action('admin_enqueue_scripts', $plugin_admin, 'enqueue_styles');
        $this->loader->add_action('admin_enqueue_scripts', $plugin_admin, 'enqueue_scripts');
        $this->loader->add_action('admin_menu', $plugin_admin, 'setup_plugin_menus');
    }

So based on your input I tried to pass an instance of the loader method to the Manage_Admin too. When Manage_Admin constructs it only stores those passed parameters locally in the object. Then when Manage_Admin::setup_plugin_menus runs it does this using the passed loader reference:

       global $hook_suffix;

        $hook = add_menu_page(
                'Plugin Manage', 
                'Plugin Manage', 
                'manage_options', 
                'plugin_manage_options', 
                array($this, 'render_page_content'), 
                'dashicons-money-alt'
        );

        $this->hook = $hook;
        if (!isset($hook_suffix)) {
            $hook_suffix = $hook;
        }
        $this->MT = new Plugin_Manage_Table($this->plugin_name, $this->plugin_version);
        $this->loader->add_action('load-' .$hook, $this->MT, 'load_user_table_screen_options');

(note when I try to move the last two lines into that objects constructor and put a fixed string in for ‘load-screen-option’ instead of appending $hook I get this error:

Fatal error: Uncaught Error: Call to undefined function convert_to_screen()

There is definitely something haunting me with how the wp_list_table is getting setup but I’m unable to figure out a way to debug it as it seems the WP_Screen object is somewhat confused. There seems to be no change in how the screen_options not finding the correct table object.

• This reply was modified 3 years, 6 months ago by EricB50.

Thanks. I’ll experiment with some of those suggestions to see what works.

Ok thanks. I’ve been looking at this object using get_current_screen.

It seems to be ignoring what I’ve set. For example when I look at the current screen:

_options:WP_Screen:private] => Array
(
[per_page] => Array
(
[label] => Stalls Per Page
[default] => 50
[option] => stalls_per_page
)
)

However this does not appear to have any impact on the Screen Options as it is populated with column names and item counts and per_page settings that do not match what is shown in the object. It does show the Pagination for Stalls and set at 50 but it does not seem to be carried into the wp_list_table as 20 are shown per page.

Anyway that could be related to something else. Is there an acceptable way to define screens based on tabs? Is that a valid approach or should I just change from tabs to pages?

Thanks again for all your help.

Thanks for the help. Yes I can set some tab query vars, but it’s not clear to me how to get the screen options to only examine one table dataset. It seems to be pulling data from whatever table instance was most recently accessed. Is there a way to specify to the screen options which instance to use?

It’s a bit of a mystery to me how the screen options interface with the wp_list_table object.

I discovered the root cause and it does somewhat relate to set_pagination_args() but it is also a problem of scope which isn’t quite clear to me yet.

There is another plugin that is extending WP_LIST_TABLE. I noticed that both that plugin and my plugin have a prepare_items routine that calls set_pagination_agrs().

Even though the namespace appears separate to me they seem to be overriding each other. I set a page parameter inside each to return immediately from the prepare_items routine:

        if (isset($_GET['page'])) {
            if ($_GET['page'] != 'plugin1_options') {
                // not viewing this table
                return;
            }
        }

This fixed the pagination values from being overwritten by the other extended object. I’m probably missing something but this seems like a good way to end up with conflicts in the plugins. They are declared like this:

Class plugin1Table extends WP_LIST_TABLE
Class plugin2Table extends WP_LIST_TABLE

And each make a similar call inside their own class method of prepare_items:

$this->set_pagination_args(array(
            'total_items' => $totalItems,
            'total_pages' => $totalPages,
            'per_page' => $perPage
        ));

However they seem to be sharing the same pagination memory space. Is there something I can do to avoid this? I’m not sure what I’m doing wrong here but I’m new to the WP framework.

Thanks again.

• This reply was modified 3 years, 11 months ago by EricB50.
• This reply was modified 3 years, 11 months ago by EricB50.

Thanks I’ll look into that.

It seems that pages must post some data to select templates between pages? Is this how WP works?