Message and Info elements

[hnla]

Need to find a way or approach to managing error message elements.

Current initial issue is trying to determine what ID's and classes are actually needed and probably adding a class 'message' to provide the parent class for sub rulesets .message.info if we're to avoid the pure and utter evil that are ID's!

Second issue is perhaps looking at gathering all template instances into one include so that we don't have to find however many instances across files in order to manage this aspect in the future.

[imath]

Could we avoid IDs in these outputs, because there can be more than one message displayed on the page.

FYI I'm using the .bp-feedback class for my UIs (invites && messages). I guess the decisions made will probably have an impact on it :)

[hnla]

bp-core-functions: bp_core_render_message() is a slight annoyance in being able to easily update classes and could do with updating.

[hnla]

@imath I'm trying to avoid ID's this is the point really, if there is more than one message displayed per document then as they all seem to carry the ID '#message' how did we get away with the obvious error before?

'.bp-feedback' works I did spot that use but I was thinking of a more generic '.bp-messages' to use in place of '#messages' but then it becomes the slight chore of finding how and where we build or render these message elements and updating them.

[hnla]

right there's an annoying inconsistency here with functions in core rendering messages with a class bp-template-notice and elements in actual templates having a class info.

For now I'm going to try and gather the true template notices into one include and add a bp-template-notice class and use that as the parent token and info as the sub class; however equally .bp-feedback could be used but bp-template-notices exists and is the harder one to update.

[imath]

@hnla you should have a look at this commit: 658def888601aa6ed4f788827fafff10b3e23881

I've created a template tag for the template notices :)

[imath]

More globally, we can replace the bp_core_render_message() with our own :) Template notices are inside a BuddyPress global so we can easily catch them! Except maybe for the avatar UI..

[hnla]

See those, cool, sadly I know see too many areas where something simple has issues in the way like class-bp-blogs-recent-posts-widget.php not really sure why widgets should live in core or perhaps they should but then maybe it should but I can't reach the hardcoded markup and creating a new widget instance just seems overkill.

[imath]

Hum, we can deal with it. For instance i've unregistered the Sitewide notice widget. We can do the same here and simply extend class-bp-blogs-recent-posts-widget.php to edit the display method and register it again :) There are other widgets like this one ?

Hum i think it's actually a bug! In the groups widget class i've found this:

<div class="widget-error">
    <?php _e('There are no groups to display.', 'buddypress') ?>
</div>

[hnla]

inconsistency :(

What I dislike though is de-registering then re-factoring under a new bunch of code then re-registering it just feels messy, code all over the place :)

[imath]

I'll look at it, if it's a bug, i'll open a ticket on trac

[imath]

I really think there should be a new template for messages/info into common ;)

Then we could use a specific function to render notices or any other user feedbacks.

[imath]

Ok this message think is really annoying me.

So this is the strategy i suggest:

• build a new common template for sitewide notices, template notices and developer notices
• Unhook core add_action( 'template_notices', 'bp_core_render_message' );
• Do our own business in BP Nouveau
• Add a link to close the notice.

Any objections ?

[hnla]

No objection, it is a problem area, solutions are required one way or another, I'm concerned though we're tackling stuff that might be Core rather than template side stuff? However more I think the more I don't care too much if Core handles this sort of stuff or new functions run from the theme class in buddypress-functions.php

Of course a really great solution run from buddypress-functions is only available for that pack.

[imath]

Leaving it open so that i don't forget to work on the scenario described in https://github.com/buddypress/next-template-packs/issues/30#issuecomment-227645744

[hnla]

Hugo apologizes for clicking the hugely big button to close comment rather than the one much smaller to simply submit comment.

[imath]

ahah no problemo :)

imath. http://profiles.wordpress.org/imath/

Le 22 juin 2016 à 19:37, Hugo - hnla notifications@github.com a écrit :

Hugo apologizes for clicking the hugely big button to close comment rather than the one much smaller to simply submit comment.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.