Hiding/deactivating functionality

  • Resolved Davood Denavi

    (@binarywc)


    5 years, 11 months ago

    We have created custom post types that we use as user profiles. The post types are employee and employer. We are using the default WP profile field “website” to identify the logged in users profile. We are having a couple problems with the profiles.

    1) users can review themselves (the reviews section uses the default wordpress comments system. This might be doable without straight php but I still would not know where to start).
    2) users can favorite themselves (We are using a plugin to allow favoriting of posts).

    I’ve seen other sites use “display: none;” css for just the current users page to hide parts of a page for the logged in users if they are on their own profile. Was this done by embedding css in php? I’m just not sure where to start looking for hints on how to accomplish it.

    Thank you in advance for the assistance.

Viewing 15 replies - 1 through 15 (of 15 total)
  • Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    If it’s in CSS, it’s hackable. If you want this functionality, it’s proably best done in the PHP, disabling that output when the user is the current_user.

    Thread Starter Davood Denavi

    (@binarywc)

    Thanks Steve for the input. Maybe I am missing something here but we need to not only disable it but also hide the elements from the screen.

    Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    Sorry, I didn’t see it was you, Davood.

    Anywho, if you don’t output the elements in the PHP, is there anything to hide in the CSS.

    If you want to play with CSS, check the <body> tag on pages. There should be a class something like “logged-in”. Offhand, I forget the exact text.

    Thread Starter Davood Denavi

    (@binarywc)

    I guess maybe I will contact the developer of the plugin we are using for favorites for assistance because that is the one that I was thinking to use CSS for. I can easily hide the comments form using php my only issue is we want the comments to still show up but the form to be deactivated. What hook/call do I have to use in the php to hide just the form?

    Thanks again for the assistance.

    Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    I think you’d need to add a read-only tag to the HTML so the comment couldn’t be edited. It depends on how it’s all laid out in that plugin.

    Thread Starter Davood Denavi

    (@binarywc)

    No, I am asking about the default comments form. The plugin thing is a whole different feature.

    Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    Check the template for single.php. You should see where it calls the comment form.

    Thread Starter Davood Denavi

    (@binarywc)

    Yah, i did see that.. but it seems to be hiding the comments and the form when I remove that…. is there a way to hide just the form?

    Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    Look inside the function it calls to see if there are any hooks/filters available.

    Moderator bcworkz

    (@bcworkz)

    Hi Davood. The specifics are theme dependent, but typically the call on single.php will load the comments.php template. That template should have separate calls to display comments and display the form. The form is usually output with a call to comment_form();

    You can wrap this call in a conditional that checks if the current post relates to the current user. You could instead simply disable the submit button through the filter ‘comment_form_submit_button’ by inserting the disabled attribute into the input tag. Realize that the presence of the form, even if hidden or disabled, allows a clever user to submit form data to your server anyway. For true security, you must prevent WP from processing form submits server side. Use the ‘preprocess_comment’ filter to determine if the submitted data should be permitted or not.

    Thread Starter Davood Denavi

    (@binarywc)

    I am not sure if this matters or not but we are inserting the comment form using a short code.

    I tried to edit comments.php and add an if statement that only shows the comment form when logged in users are not on $current_user->user_url. However, when I had that code there it also took the form away on all other profiles too.

    I’ve used other filters in WP before but do not understand the filter stuff you are suggesting I do bcworkz. Would you expand a bit further?

    Thanks in advance.

    Moderator bcworkz

    (@bcworkz)

    If the shortcode is calling comment_form() then it is of no matter for filters. But to suppress the output entirely by wrapping in a conditional, you would need to alter the shortcode handler function itself.

    The ‘comment_form_submit_button’ filter passes the entire input tag for the button. Use string manipulation functions like str_replace() to insert a disabled attribute before returning.

    On further thought, ‘preprocess_comment’ filter is not the best choice to secure rogue submittals. Better would be ‘pre_comment_approved’ filter where your callback function is passed both the status determined by WP as well as all the submitted data. If the data is inappropriate, return either 0, 'spam', or a new WP_Error object, depending on how you want the comment handled. Returning 1 will approve the comment.

    Thread Starter Davood Denavi

    (@binarywc)

    This seems like some complex stuff that I will need to play with to get it right. I am still lost on how to use the filters though. Most of the filters I’ve used in the past were code provided to me by theme/plugin developers and they weren’t wrapped in conditionals at all it was just the filter pasted directly into my functions.php or custom-functions.php file.

    I’ll play with this soon… probably not today though and let you know if any further questions arise.

    Thanks for the help so far!

    Moderator bcworkz

    (@bcworkz)

    If, how, and where conditionals are applied depends on the filter being used. Very specific filters are less likely to need conditionals than very broad filters. How filters work is indeed rather difficult to grasp at first. I say it’s well worth spending the time to really understand how filter and action hooks work. They are fundamental to customizing WP. The multi-page section on hooks in the Plugin Handbook may help in gaining an understanding. The concept applies to themes as well.

    I find it very useful to locate the source code where hooks are applied, by calling either apply_filters() or do_action(). This is the only good way to see what is being passed to your callback in context, as well as what happens to return values (in the case of filters, returned values from action hooks are ignored). Those functions serve as the “trigger” that “fires” the specific action or filter. They call all callback functions that were added to the specific tag in question. Additionally, the inline documentation in source is often informative.

    For filters, apply_filters() takes whatever is returned by the callback and returns that value itself. Source code reveals what happens to the returned value after applying all the added filters. Take the ‘pre_comment_approved’ filter as an example. Check out the source code. You can see two parameters will be passed to your callback. The first parameter ($approved, after the tag itself) should always be returned, altered or not, by callbacks. As you can see, the return is in turn returned by the wp_allow_comment() function.

    By checking the code reference, we learn wp_allow_comment() is called by wp_new_comment(). Checking its source code, we see the returned value is part of what gets saved when the new comment is inserted into the DB. WP handles the comment based on the value saved for $commentdata['comment_approved'], which can be 1 (true), 0 (false), or 'spam'.

    Part of understanding hooks involves understanding the context in which they are used. Each filter’s context is different, and the only way to see the context is by examining the source code around where the filter “fires”. I hope this furthers your understanding of hooks. Once you truly understand how these work, I think you’ll find it’s really not that hard to understand after all. It just takes an effort to grasp the concept.

    Thread Starter Davood Denavi

    (@binarywc)

    Thanks for all the help on this. I never did completely figure out what we were trying but it’s okay the client decided to go in a different direction.

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Hiding/deactivating functionality’ is closed to new replies.