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.
, and as far as it looks, David’s tip solves the issue, correct?
