Support Forum » User Profile

Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • Digital RockeryDigital Rockery
    Participant

    Hello Peter,

    As a follow up to the above, I have decided to use shortcodes to display the fields.However, they are also not working. Whether is using inbuilt shortcodes eg [rwmb_meta id="ehven_adopting_family_profile_display_name"] or creating one

    function display_display_name_shortcode($atts) {
        // Extract shortcode attributes
        $atts = shortcode_atts(array(
            'post_id' => get_the_ID(), // Default to current post ID
        ), $atts);
    
        // Get the 'display name' metabox field value
        $display_name_value = get_post_meta($atts['post_id'], 'ehven_adopting_family_profile_display_name', true);
    
        // Return the 'display name' metabox field value
        return $display_name_value;
    }
    add_shortcode('display_name', 'display_display_name_shortcode');

    What might be the issue?

    Digital RockeryDigital Rockery
    Participant

    Hello Peter,

    This solution provided only works for the native WP fields. Also, it doesn't have a provision for images and galleries as User Meta field isn't available there for selection.

    Digital RockeryDigital Rockery
    Participant

    I just noticed something that might be helpful: When echoing get_queried_object_id() and $post_id:

    1. get_queried_object_id() returns correct ID of the project post on which the MB Frontend Submissions form is displayed (and used to create update posts)
    2. $post_id return nothing
    3. This behavior is the same whether the test echos are placed directly after the shortcode or after the MB Frontend Submissions form
    Digital RockeryDigital Rockery
    Participant

    I will certainly do that if there is no other choice, but given that there might be quite a bit to re-implement in a new [child] theme on a new server (all the work thus far is implemented in an Astra child theme), I'd like to try to confirm a couple of things with you:

    1. Is it indeed the case that my config as currently implemented...
      1. MetaBox, MB Frontend Submission, and MB Relationships, plus...
      2. add_action for mb_relationships_init in my original post, plus...
      3. publicly_queryable setting change you specified, plus...
      4. mb_frontend_form shortcode change you specified, and...
      5. add_action for rwmb_frontend_after_process you outlined with fixed ID's...

      ...already accounts for all that is required for the specified relationship to be created upon submission via front-end form? There is nothing else you can suggest checking before reimplementing with a default theme?

    2. Is there a demo somewhere (or walkthrough article/tutorial) that I can look at?
    3. Are there any test or profiling tools I can install in Staging (or Dev) to provide you with more info (I already have Query Monitor running)?
    4. Assuming for a moment that the same problem persists even in a reimplemented version, would you be able to have someone log in to the new server and take a look?

    Apologies for asking some of this stuff again. I'm just trying to avoid reimplementing this on a new Stager, as I cannot deactivate everything in Production (or even on the current Stager). I'm happy to do all of this, of course, but I'm also hoping that someone's memory or alternative ideas might be jogged by one more round of questions...

    Digital RockeryDigital Rockery
    Participant

    Thank you for the assistance!

    So far, no joy: Relationship not created.

    What do you find are the most common errors in configuring this sort of functionality? Is it possible I'm missing a component? Making calls in the wrong order? Maybe some other CPT config that is known to interfere with this functionality?

    Digital RockeryDigital Rockery
    Participant

    Is there a way to share JSON and images privately? The client will not appreciate public displays of this sort (yes, we have several clients like that).

    I'd be happy, when done, to share conclusions here for anyone that might come to this thread with similar issues.

    Digital RockeryDigital Rockery
    Participant

    Interesting, thank you.

    This indeed works as expected, but it raises a question: Will this approach have any deleterious effects if $field_value includes non-wysiwyg fields?

    I ask this, because our templates assemble together the values of different fields (and field types), into a single payload that may (or may not) include wysiwyg fields. And, of course, it would be better to use this technique once at the final render instead of every place in which a wysiwyg is called, especially since we switch wysiwyg availability on and off in some cases with conditional logic.

    Related question: We need to be able to render shortcodes inserted into textarea fields as well, but I don't see a note like the above in the textarea docs. Is this technique expected to also work with textarea fields?

    in reply to: Save CPT content and title to MB Custom Table? #39399
    Digital RockeryDigital Rockery
    Participant

    Please clarify "Saving the post title to the custom table will lead to some unexpected issues." If this is a bad idea, I won't do it, but I'd like to know more about your concern.

    Regarding the content: Yes, creating alternative/replacement fields to use in place of the native WP content has indeed been the strategy thus far. The reason I asked the above, however, is that I wanted to keep the Gutenberg functionality for the main content on the CPT page.

    Is there a way to load Gutenberg into a Metabox-generated field that is saving to a Custom Table?

    in reply to: Custom table *per* CPT, or one table for all CPT's? #37276
    Digital RockeryDigital Rockery
    Participant

    To be clear, I'm also open to having one table per meta box, but if that's overkill, the middle ground in my original plan seems quite maintainable.

    Which raises a related question: At one point do we see a benefit to splitting storage into additional fields/columns? 20 columns? 100?

    in reply to: Custom table *per* CPT, or one table for all CPT's? #37275
    Digital RockeryDigital Rockery
    Participant

    Thank you so much for this info.

    To be clear, my plan was not to store fields from each meta box in a dedicated table (one table per meta box). Rather, I was asking about all fields of all meta boxes associated with a particular CPT in a dedicated table (one table per CPT, in essence, rather than one table per meta box).

    Does this change your answer at all?

Viewing 10 posts - 1 through 10 (of 10 total)