SOLVED: Ultimate Member (and others) not working properly with Bricks - Bricks issue

Bricks Version: 1.6.1
Browser: Edge 108
OS: Ubuntu 21

For the past few weeks, I have been trying to implement the functionality of blocking access to the site’s resources using plugins like “Membership”. However, each of them caused the problem that the restricted pages were blocking the Rich Text fields contained in the header and footer. Recently I’ve been struggling with Ultimate Member, I’ve been able to unblock post titles and menu items using various settings, but the footer is still blocked.
Today, after many hours of painstaking research, I discovered why all Membership type plugins are incorrectly handled in Bricks. I’ll show it using the Ultimate Member code as an example, but I’m guessing that the cause is the same in every plugin, because imho the problem lies with Bricks.

First screen from Bricks footer edit:

Now results on website with blocked content (post), please note the blocked, by content substitution, Rich Text fields:

Now the filter function from Ultimate Member, registered under the hook “the_content”

add_filter( 'the_content', array( &$this, 'filter_restricted_post_content' ), 999999, 1 );

function filter_restricted_post_content( $content ) {
    if ( current_user_can( 'administrator' ) ) {
        return $content;
    $id = get_the_ID();
    if ( ! $id || is_admin() ) {
        return $content;
    $ignore = apply_filters( 'um_ignore_restricted_content', false, $id );
    if ( $ignore ) {
        return $content;
    if ( $this->is_restricted( $id ) ) {
        $restriction = $this->get_post_privacy_settings( $id );
        if ( ! isset( $restriction['_um_restrict_by_custom_message'] ) || '0' == $restriction['_um_restrict_by_custom_message'] ) {
            $content = stripslashes( UM()->options()->get( 'restricted_access_message' ) );
        } elseif ( '1' == $restriction['_um_restrict_by_custom_message'] ) {
            $content = ! empty( $restriction['_um_restrict_custom_message'] ) ? stripslashes( $restriction['_um_restrict_custom_message'] ) : '';
        // translators: %s: Restricted post message.
        $content = sprintf( __( '%s', 'ultimate-member' ), $content );

    return $content;

Now I add to this filter one line, with output log to browser:

And now the result that was logged (embedded in the content of the page):

In green I have marked the real content that Ultimate Member hides, in red the ID of the post (this is the ID of the whole post).
When we look at the PHP code it comes out that Bricks calls the “the_content” hook when rendering the footer every time it hits the Rich Text field, and the UM plugin (and any other of its kind) takes the ID of the post (the whole one with the footer in it) and finds that it needs to block, so it substitutes the content to restricted message. I consider this a mistake by Bricks. It doesn’t do it with plain text (Basic Text) and it shouldn’t do it with Rich Text.

After testing about five membership plugins, I gave up and decided to build it from the ground up using conditions, which hasn’t been easy, but I have to do it anyway. The fact that I had to go the manual route was exacerbated by the fact that I had seen threads on this forum where this had been reported, but nothing had been done about it as of yet.

Interesting. I use PaidMEmbershipPro and hadn’t come across this issue.
Mainly as I never use Rich Text in the header or footer I suspect.
I’ve tested it and do see the problem with Rich Text now.

My way of working is to produce the entire site layout publicly accessible. Then for each post, which i create in gutenturd, I just use the Content restriction which the plugin provides.
I’ll also use the same for some pages if I want to hide them completely.
Seems to work ok for the content restriction, but there are plenty of other issues - such as how to style the Access Restricted message. This always breaks the site layout sadly.

At the moment I’m finding Bricks rather too limited for real use as a Membership site of any complexity.

Maybe adding an api entry to the conditions of each element would allow membership plugins to then provide their own restriction options?



Will this thread be taken up by someone from the team?
This problem has appeared on the forum several times and there was no solution, and now the matter is made easier, because from my analysis the reason for the incompatibility of Bricks with this type of plugins.


Maybe now, after the release of 1.6.2, someone will finally look at the problem described here?

But why not try to make Bricks more widely supported?

Answer from Ulitimate Member plugin developer:

"First of all, we care that our plugin works with WordPress and its new block editor. We fix obvious problems with our plugin.

Unfortunately, Bricks Builder is not a commonly used plugin. We have a list of 3rd party plugins integrations and Bricks Builder is not included in this list.

Sorry, but we can’t help you with this plugin. Try to push support for this plugin."

Nice sleuthing with this one. We’ve been building out more membership sites this year for clients requiring access tiers so this definitely sounds like it could be a deal breaker if not resolved soon. How can we get this pushed up the log?

1 Like

I don’t know why, but the matter is ignored by the BRICKS team. And I have to finish the Ultimate Member page by the end of February (or other membership system). So I think I have to do everything again in another builder. Although I bought a license for Bricks :frowning:

Use the ‘um_ignore_restricted_content’ filter that Ultimate Member provides to ignore the restrictions for the header and footer.


that seems to solve the problem! I still need to test more cases, but 99% will be okey, thanks a lot David!

Hey Jacek,
Sorry for the super late reply. I had to take myself out for personal reasons for some time.

Unfortunately, member plug-ins are still a red rag for me because I have no experience with them, which makes understanding/identifying the problem much more complicated and takes a lot of time. Accordingly, I’m glad that some of the other users have jumped in :raised_hands: , and as far as it looks, David’s tip solves the issue, correct?


It was just a workaround really, as I noticed that membership plugin had a filter (from the screenshot above) that could prevent this specific issue. But the same issue happens with other membership plugins, which wouldn’t have the same filter to work around it.

The main problem is that in the rich text element uses…

apply_filters( 'the_content', $content )

Which is the same as the membership plugins use. As the_content is usually used to filter the main post content and so is what the membership plugins commonly use to show/hide the post content based on that post’s restriction. This is causing the rich text element content to also be hidden (if there is a restriction on that page), regardless of where it is on the page.

That the_content filter is likely being used inside the rich text element, to make sure that shortcodes work correctly, or similar, but that’s the main jist of the problem. Ideally, the rich text element would solve this in a different way, avoiding the use of that specific filter, and then all the membership plugins wouldn’t have this issue.

It is as David @wplit writes, it is a workaround that works in this case, but the problem is deeper and lies on your side. Specifically in the handling of Rich Text element. In fact, there is enough shown in this thread that you should understand what the problem is and how to fix it.

Thanks a lot for showing up here, because I was already losing faith in support :upside_down_face:

Unfortunately, I have a second problem with Ultimate Member and Bricks, and I do not know where the cause lies this time.

The problem appears on a page that is selected in the WP configuration as “Posts page”

In this situation, a page that has posts in the query results that have restrictions automatically blocks all Rich Text elements (but not the entire page):

It looks like the page inherits the restrictions from the posts, because when I turn off the restrictions to the posts, Rich Text has the correct content set in the builder.

Unblocking also occurs when I select another page as “Posts page”:

Then content in Rich Text is unlocked:

Maybe David @wplit you can find a solution this time too, I didn’t manage to think of anything all day :frowning:

Trying doing the same, adding the filter, then removing it after.

In my example earlier it was doing it before the header and after the header, (and then again for the footr) you could add in code elements above and below the part that is going wrong and add and remove either side of it in the same way.

Add filter

add_filter( 'um_ignore_restricted_content', '__return_true' );

Remove filter

remove_filter( 'um_ignore_restricted_content', '__return_true' );

Thanks David @wplit ! That helped.
@timmse But this issue (support for membership plugins) needs a major overhaul in Bricks

We’re currently working on a custom filter / helper function which you will soon be able to test :slight_smile:

YEAH!!! Big thanks!!!
Happy Valentines Day! :heart_eyes:

Great to hear, thank you!

Hi guys,
As already mentioned yesterday, we’ve fixed this bug by replacing every the_content filter with a custom filter in Bricks 1.7 beta, now available as a manual download in your Bricks account: Account – Bricks

Please let us know if you are still experiencing issues :v:

Best regards,