LabSecrets

Hi Bangbay,
thanks for the fast response.

This makes sense regarding the first part of my question. We use Members (by Justin Tadlock) to customize roles… so it sounds clear that if we add those FOUR capabilities (not just upload_files) to our two membership roles (custom roles) we will be able to solve the access to the editor issue. This is not likely, because we don’t want front-end users to get to back end.

Can you please identify in what file and maybe what line the conditional check for capabilities is located? Perhaps if it is pluggable I can modify this with a filter in functions.php?

My second question is still unclear:

In earlier versions of the plugin (or perhaps because it was an earlier version of WordPress), was it “not” possible to edit the images on the front-end instead of sending folks to the back-end of the admin dashboard (as it appears to do now)??

Sending folks to the back-end is not an option for us, and even a basic “crop” function would be fine on the front-end (which is what I remember happening before WP 3.8.x).

Can you please clarify this second point and if you know, confirm that the editing behavior “is” or “is not” possible from the front-end only.

Thanks a million!!
spence

I’m having the same trouble. Prior to WP 3.8.x we have integrated wp-user-avatar successfully at 1wd.tv where forum participants could upload, crop and later edit their avatars all from the front end.

Since a customer notified us that they can no longer do any of this, we have isolated and tested the following:

1) We are on latest version of WP 3.8.1
2) We are on latest version of bbPress 2.5.3
3) There are no .js or other plugin conflicts (we’ve been stable for a while, no changes, and nothing shows in debug or console)
4) The issue seems to be a combination of two factors:
a) In previous mix of wp-user-avatar and pre WP 3.8.1 the avatar images were editable and reachable by “non-contributors” and “non-authors” from the front-end, when on the bbPress edit profile pages. Now they are not.

If a user has a role of anything other than admin, contributor or author, it redirects them to our fallback “my-account” page because the role does not match with any of those three…whereas before they could get to their image right there, inline, on the front end (was wonderful!)

b) When we change the test user role to any of the above three, then the “edit image” button WILL send the user to the BACK-END of wp-admin dashboard… which is counter-productive. The entire benefit of this plugin previously was that it allowed a “front-end” access to editing the avatars, because we never want anyone on the back-end who is merely a bbPress participant.

I’ve tested this to death and I’m convinced that the solution is a mix of the new WP 3.8 image handling and the mods in the plugin…because even if I revert back to an earlier version of wp-user-avatar (1.5.7 for example), the behavior is exactly the same.

I am hopeful that the problem here is clear…and that you can find a way to restore the front-end “only” functionality so that non-contributing members of a community site can upload, edit and change their avatars again.

Best regards!!
Cheers,
Spence

Not knowing where or what you are trying to do with this… or what you have installed with other plugins or themes (that may be causing a conflict), the only other suggestion I have is to add a priority to the action (11), and see if this works. I’ve reverted back to the original action syntax as well.

if (!is_admin()) add_action("wp_enqueue_scripts", "jquery_to_top", 11);
function jquery_to_top() {
wp_deregister_script('jquery');
wp_register_script('jquery', "//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js", false, null);
wp_enqueue_script('jquery');
}

Upon reflection.. actually, probably more like this:

if ( !is_admin() ) {
add_action("wp_enqueue_scripts", "jquery_to_top");
}

function jquery_to_top() {
wp_deregister_script('jquery');
wp_register_script('jquery', "//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js", false, null, false);
   wp_enqueue_script('jquery');
}

Looks like your syntax is off. I believe it should be something more like this:

function jquery_to_top() {
if ( !is_admin() ) {
add_action("wp_enqueue_scripts", "jquery_to_top");
wp_deregister_script('jquery');
wp_register_script('jquery', "//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js", false, null, false);
   wp_enqueue_script('jquery');
}
}

Also, you might checkout this resource:
https://stackoverflow.com/questions/4927352/adding-a-jquery-script-to-wordpress-admin

We do this all the time at LabZip and 1WD tv so if you need any other help, just drop me a line ??

Cheers!
spence

Hi Advent,

While you may want to adjust the width attribute for the size of your particular graphic (used as your logo), here is the CSS you want.

If you are using a child theme, please put it into the child theme style.css. Otherwise, you can add it with the Responsive Theme Options in the Admin Dashboard.

#logo {
float: none;
margin: 0 auto;
max-width: 300px;
padding-top: 30px;
}

We have used this method a lot at 1wd.tv and found that it’s possible to do some pretty powerful mods with some basic css.

If you need any more help, please let me know ??

Cheers!
spence

Ulrich,
if all you want to do is make the checkout page full width, do it via css and the body class.

body.woocommerce-cart #content {width:100%;}

We’ve had no problems using CSS to fix many quirks of the WooCommerce layouts when we integrated it fully into Responsive LabZip.

If you use a child theme, remember that (to override default WooCommerce templates) you don’t need to use the folder name of “templates” when putting the replacement templates into a “woocommerce” folder in your child theme.

Cheers,
spence

Heather,
Please watch and follow this free video:

https://labsecrets.com/2012/01/23/buddypress-and-bbpress-forums-made-easy/

Your solution is to remove the “forums” page and delete from trash, etc…as shown

Cheers!
Spence[ Signature moderated. ]

You have to delete the page that uses “forums” and empty the trash. Make sure you then create new menu item in appearance/menus for “forums”, as that slug will now be used by site wide forums. See this video: https://labsecrets.com/2012/01/23/buddypress-and-bbpress-forums-made-easy/

Cheers!
Spence

Hi Guys,

Found this thread and just wanted to drop in our suggestion that spherical has it right when he stated:

An update to Responsive every day for the past 3 days, 10 in 5 weeks, is out of the norm.

One of the reason why Responsive has been so popular, and why we have adopted it as our core installation theme (over even WooThemes which we use extensively) , is exactly because of the fact that Emil is “out of the norm.”

He is one of the ONLY theme designers in the WP repository who treats his free theme with as much love and attention as any premium theme author.

Since it is relatively trivial to turn off automatic update notices for Responsive, and all of the improvements made by Emil have been directly in response to requests made by more than 1200 WP users in the ThemeID forum, does it not make sense that his current path is setting a new standard for how WP repository themes should be handled?

To say to a passionate theme author such as Emil that he should “not work so hard to improve his product” sounds like something one might here amongst employees of the post-office… “don’t work so hard, you’re going to make us all look bad…” Is that really what we want for WordPress authors?

Cheers!
Spence