• Resolved dkurth

    (@dkurth)


    have you ever seen it where the CMB2 just suddenly, upon clearing the cache, does not want to display anything further. I watched it disappear. If I reload the entire site from a backup, with the same code, it reappears for a time.

    Any thoughts? It is true that I am loading the system, because I need to display different record types for different types of data, so I am hiding records.

    1. Have you seen the forms disappear

    Wondering if I have to do the dreaded activity for setting up multiple CMB forms for the front end. So far, the back end, which has the heavier load, seem to work just find.

    Your thoughts?

Viewing 11 replies - 1 through 11 (of 11 total)
  • Thread Starter dkurth

    (@dkurth)

    … it is why I needed the post id BEFORE the initialization of CMB2. Then I could have just displayed the fields I needed and not going through this massive exercise of hiding records.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    when you do a view-source, does the page load completely all the way to </html> or does it stop part way? You may be running out of memory or some sort of error occurs preventing the loading of the rest of things.

    Also for existing posts, you can always get the post ID from the admin URL on the admin side, and then for frontend get the queried ID via get_queried_object_id()

    Thread Starter dkurth

    (@dkurth)

    Interesting you should say that about memory. I thought of that. It does goes all the way to HTML. I own the server, so I allocated a heck of a lot of memory and this is on a test site, where I have almost no plugins’ installed.

    This issue is specifically on the front size. While the front end does not display, the admin side does AND using the get_queried_object_id() results in a ListId of 0 on the admin side. Which has always been the problem.

    I am doing this via a custom post type. Is there another location I can call add_action( 'cmb2_admin_init', 'mmdlist_add_manual_form' );

    Thread Starter dkurth

    (@dkurth)

    …FYI, the front end is a bit more difficult, since while the records are inserted, via shortcode to a place on the profile page. Thus the post id, when the fields are being setup, does not work. It is almost like I have to load the data, specific to the user PRIOR to CMB2. But each record set contains different, thus what I display is different per record.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    cmb2_admin_init only runs on the admin side. there is also cmb2_init available for your frontend needs.

    Thread Starter dkurth

    (@dkurth)

    Yes, there is. there is a unique cmb2_init on the front side as well.
    add_action( 'cmb2_init', 'mmdlist_add_user_manual_form' );

    Also use the prefix as stated by your associate.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Upon some further thinking, if you’re just using a random-ish page to simply show the form, and it’s not a page that has the current meta, then get_queried_object_id() won’t be as useful.

    One of the variables/objects/etc has to provide the current ID being rendered, I don’t know it off the top of my head. I believe one of the items you’re pulling in to render the form would have it or at least a method to fetch the ID being rendered.

    Thread Starter dkurth

    (@dkurth)

    Exactly. I have the post id within the database record. That is what I am using presently and the show_on_cb to modify the record accordingly. Assuming the number of displayed records, based on the user email (it should be the same), I then loop through the records and change the visible setting by returning the 1 or 0.

    So record display 1 will be the same record as the returned database record. it was working, but I am being to suspect that, that method is too taxing for CMB2. Because after a time, the problems started..so something was overloaded and just shut down. So I am reducing the load at present.

    This is sorta a pain in the ass..

    Thread Starter dkurth

    (@dkurth)

    Question…do you use a “different” action hook for records on the front end?
    add_action( 'cmb2_admin_init', 'mmdlist_add_manual_form' );

    It says “admin” and given the past need for unique names with the prefix in it, such as
    add_filter('cmb2_override_MMDListsRecord_meta_save', 'save_custom_data', 10, 2);
    where the MMDListsRecord is the prefix, I am wondering if there is the same for the front end records and THAT is contributing to CMB2 confusion.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    cmb2_admin_init and cmb2_init are generally equivalent to admin_init and init but are run, i believe, after CMB2 has been loaded. There’s no override hook equivalents that I’ve ever seen for those two.

    Thread Starter dkurth

    (@dkurth)

    So here is what happened. I had allocated by the server over a 1000MB of memory, that was defined in PHP. BUT, WordPress has another memory limitation. 40MB, there are very crunched by the large amounts of data being passed . The stack was getting crunched. So I modified the WordPress parameters raising it to match the server. the problem went away.

    What happening in the detailed version, is, passing the array of data, back to the CBM2 was failing. I watched and checked the data going back to CMB2. Nothing arrived. Thus array values where not being transferred.

    • This reply was modified 6 years, 10 months ago by dkurth.
Viewing 11 replies - 1 through 11 (of 11 total)

The topic ‘DISAPPEARING CMB2’ is closed to new replies.