Security Alert: 26 BuddyDev accounts compromized in brute force attack.

BuddyDev

Search

[Resolved] Member type pro compatibilty Gwangi

  • Participant
    Level: Enlightened
    Posts: 41
    Linklusion on November 7, 2019 at 1:16 pm #26317

    Hi Brajesh

    I use template GWANGI
    Directory URL from Member type pro does not display right when member page is with sidebar left or seidebar right
    Here’s screenshot :
    SIDEBAR LEFT https://prnt.sc/ptoezs
    SIDEBAR RIGHT https://prnt.sc/ptof8u
    FULL WIDTH https://prnt.sc/ptofgm
    DEFAULT https://prnt.sc/ptofn3

    I got in touch when developper of Gwangi, they checked and apparently problem is due to Member Type pro that breaks the template.
    They gave me a message to forward to you explaining source of issues (below)
    Is that something you can fix ?

    Thanks
    —— Message explaining source of issue————-

    The problem is that when we activate the Member Types Pro plugin, the « get_queried_object_id() » function suddenly returns 0 for member directory pages, instead of the actual page id, and it keeps returning 0 even after we disable the plugin.

    After that, the only way we found to get back to the original working state is by clearing all transients and switching to another theme then back to Gwangi.

    The reason why this breaks the layout is because we rely on the « get_queried_object_id() » function to add a class to the container, which is responsible for displaying the layout properly. That means when « get_queried_object_id() » returns 0 instead of the actual page id, the wrong class is added and the layout breaks.

    You can find the bit of code that suffers from this problem in the « add_content_classes() » function in « gwangi/inc/grimlock/class-gwangi-grimlock.php » in the theme.

  • Keymaster
    (BuddyDev Team)
    Posts: 24706
    Brajesh Singh on November 7, 2019 at 4:56 pm #26318

    Hi Johan,
    Thank you for the details.

    It seems that Gwangi developers don’t have much experience with BuddyPress. They are incorrect in pointing about the plugin.

    The issue is related to how BuddyPress Member Types directory works(It is a core feature of BuddyPress).

    On the member types directory(say members/type/student), The queried object is not setup and that’s why they are getting 0.

    They should use buddypress()->pages->members->id. It is better choice for knowing the members directory.

    Also, they do not need to delete transient or cache or anything. These are no required.

    Regards
    Brajesh

  • Participant
    Level: Enlightened
    Posts: 41
    Linklusion on November 7, 2019 at 4:58 pm #26319

    Hi Brajesh

    I give them details, hope they will correcct

    Thanks

  • Keymaster
    (BuddyDev Team)
    Posts: 24706
    Brajesh Singh on November 7, 2019 at 4:58 pm #26320

    Sure, Please do.

  • Participant
    Level: Enlightened
    Posts: 41
    Linklusion on November 12, 2019 at 12:17 pm #26414
    This reply has been marked as private.
  • Participant
    Level: Enlightened
    Posts: 41
    Linklusion on November 12, 2019 at 12:18 pm #26415

    Hi Brajesh

    FYI, answer from Gwangi devleoppers, they do not intend to correct and keep their position
    They will adapt and make Gwangi compatible with Member Type pro if they have more interest from other users

    ———–
    Thank you for the update.

    I understand Brajesh’s point but I think it is very arguable. If you try to use Gwangi on a fresh WordPress install with the basic plugins (Grimlock, Kirki, BuddyPress and Grimlock for BuddyPress), the member directory with sidebar right template is working as expected. Then, from your feedback I understand that the sidebar right template doesn’t work anymore after enabling the Member Types plugin. Knowing that, the only conclusion that we can come to is that the plugin is doing something unusual that breaks our template as a consequence.

    Unfortunately, the solution suggested by Brajesh isn’t going to help, because we are trying to retrieve the current page id rather than the members page id. Also, the get_queried_object_id() function that we are relying on is a core WordPress feature, so if this core function doesn’t have the expected behavior there is unfortunately not much that we can do about it.

    With that being said, we don’t want to waste more of your time and continue sending you back and forth between us and the plugin developer. So our stance will be the same as it was at the start of this topic: this plugin is not compatible with our theme, and if more people start to show interest in this we will consider investing some time into finding a solution to work around this issue.

    We thank you for your investigations, and we are sorry that we couldn’t come to a favorable conclusion concerning this plugin’s compatibility.

    Of course we remain available if you have any more question regarding the use of the theme.

  • Keymaster
    (BuddyDev Team)
    Posts: 24706
    Brajesh Singh on November 12, 2019 at 12:26 pm #26416

    Hi Johan,
    It is their loss. Like I pointed earlier, they lack the correct knowledge about member types.

    They do not need to add compatibility with my plugin, they need to do it for BuddyPress Member Types feature. It is core feature not enabled by default.

    You can use our plugin or a few lines of code to enable this feature.

    https://codex.buddypress.org/developer/member-types/

    I hope the right sense prevails, otherwise, It is their loss.

    I am sorry that I am unable to do much here, as the code is form the theme trowing issue.

    Regards
    Brajesh

You must be logged in to reply to this topic.

This topic is: resolved