julie92500

Good,

I’ve just developped a patch to have a new settings – list of categories number to filter from the results.

It’s working fine. Contact me if you want the patched file.

Rgds,

Problem is with all the settings for that role stick

I’m using Extension “User Role Editor”, Version 3.12.1 (latest)

NB: “participant” is a secondary role within wordpress/bbpress, I’m surprise to found it in the role list proposed by Events Manager.

“Participant” means that the user is allowed to participate to the bbPress forums. But it says nothing about role in the multiste blogs.

I think the Events Manager is confused with “Participant”. It should ignore the secondary role and use only the primary role.

It seems I have an issue with members registered in the multisite, without any primary role (blog access is read only) and with “Participant” secondary role (bbPress).

Found in the “User Role Editor” forum : By default WordPress assigns only one role to the user. BBPress started to use multi-role feature: it assigns more than 1 role to the user at once and does that on the fly.

Says otherwise, Events Manager seems incompatible with the way wordpress/BBPress is managing multi-roles.

The regular user is most of the time with the “Participant” role.

With Events > Settings > General > User Capabilities, i can add “edit event” and “edit location” capabilities but after saving the setting, still the checkbox unchecked …

For the others regulard user with “Author” or “Contributor” or “Moderator” roles, Events > Settings > General > User Capabilities is working as expected and these users can create events.

Rgds,

not sure this workaround will work for everybody and in any case.

especially i’m not sure about the “$action = get_query_var(‘action’);” purpose which can setup some value in the $action variable and then trigger also some title rewriting later.

and i’m not sure that my test condition “if (get_query_var(‘page_id’) == wpbdp_get_page_id(‘main’))” will cover all the cases.

my only advise is that you have to manage your plugin behaviour only on the plugin pages. so you have to check such title rewriting is triggered only on WPBDP pages.

Rgds,

??

have resolved the order issue

file bpa_classes.php in bp_album_default_query_args()

change $args[‘ordersort’]=’ASC’; to $args[‘ordersort’]=’DESC’;

Everything working as before the update.

I’ve partially resolved the issue by reactivating some code in bpa.template.tags.php :

$this->pag_links = paginate_links( array(
                        'base' => $bp->displayed_user->domain . $bp->album->slug .'/'. $bp->album->pictures_slug .'/%_%',
                        'format' => '%#%',
                        'total' => ceil( (int) $this->total_picture_count / (int) $this->pag_per_page ),
                        'current' => (int) $this->pag_page,
                        'prev_text' => '←',
                        'next_text' => '→',
                        'mid_size' => 1
                ));

(this code was in comment).

After commented out the code, the pagination works again.

But, still have an issue : previously i got the last added photo on the first position of the first page. Now, i get it at the last position of the last page (reverse order).

Any idea ?

thanks for your help.

i’ve followed your recommendation with success.

My question was badly exposed (i’m not fluent in english, sorry). My concern is to have this pluging using no ressource on any page or post without gallery.

As i’m using APC object caching, i have a way to dump number of cache access during page construction in the page’s footer :

global $wp_object_cache;
foreach ( $wp_object_cache->stats as $stat => $n ) {
   echo "$stat: $n ";
}

On my web site, with your pluging running i got these :

Cache get: 4737 delete: 1 add: 1

and around 670 ms to build the page

With your plugin deactivated i got these :

Cache get: 3962 delete: 0 add: 0

and around 600 ms to build the page

=> 775 more get object with your plugin running and 10% more time. NB: I have a total of 45 plugins, only this one is consuming so many get (16% of all the gets)

The issue is not the css and js files size but the time to build the page (more than 500+ additional get object requests) then download it / interpret it by the client browser.

This is a concern for pages and posts without gallery; to have a time penalty (on both server and client side) on more than 3.000 pages for only two of them with gallery.

You are right for event adds. but comments adds not working.