BuddyPress 1.2.5 tickets are cleared out
-
Going to give it a few days to see if any issues pop up. If you’re comfortable doing a little testing, the branch of code is considered stable enough to be the next bug fix release. I’ll be combing through the 1.2.5 enhancements to see if there’s anything that can be snuck in next.
You can download it from the link on the bottom of of the page on our bug tracker and manually FTP up to your install, or
svn up
if you run your install in an SVN checkout of the 1.2 branch.Thanks to everyone that’s contributed this round. Provided no major bugs crop up, look for 1.2.5 to drop sometime in the next day or two.
-
The first row is 0, which is an even number. The second row, is row 1 Yes did know that, if I had stopped to think.
One thing worries me slightly; with the addition of the class ‘zebra’ on the tables does that not require anyone in future that might generate a table in a plugin realising they need to add this class to their table.
More importantly though from a theming point of view changes to theme files means that our own themes will break if the changes are of a significant level, I cannot simply copy over say files in /members/single without thinking very carefully as I have a lot of these presentational files heavily modified, and in advance of the 1.2.5 release have had to go through my current actual theme in development and use tortoise svn compare to try and identify changes and manually update my working files, it’s not necessarily that clear if one has caught all those changes. Overall a practice I don’t really wish to have to perform too often.
Changes to bp-default won’t happen very often, and if your theme is a child of bp-default, then you inherit these changes automatically. If not, then it’s your choice to adopt these changes or not.
I get what you’re saying, and it’s a valid concern. The ‘zebra’ class was added only because the JavaScript that was doing the striping was striping things all over the place that it shouldn’t have been. The only way to get it to stop reliably was to tell it exactly which tables it should stripe, hence the zebra class was born.
If you have problems or questions about it, ask them here or in IRC and I’ll try to help.
FWIW – winmerge is a great tool if you have to update a custom theme/etc. (Guiffy is not bad either)
@johnjamesjacoby; I don’t suppose this is the place to report an issue, so I’ll make it a question. When creating a Group, the tags are lost and have to be re-input after the final step. Is this fixed?
looks like a plugin issue: https://buddypress.org/community/groups/buddypress-group-tags/
Initially, and I would be surprised if anyone has yet to really take the plunge, one has to take the child theme route as trying to code presentational files from scratch with apps such as this would defeat even the best frontender, naturally one starts with the existing default theme folder structure, there’s nothing wrong with it and it’s how BP works, however with that copied over most of us with any experience are going to start very heavilly changing the markup (that is not critism of bp-default, which aint half bad )
There has to be a point where theme files do not suffer any changes, not that is in terms of hooks, functions, variables etc, the odd class not a huge problem as this is really not a core issue but a presentational frontend matter, and if I do not pick that change up no matter I deal with something like that my self or simply pass it by, look at the default theme in passing and realise it’s got a cool feature I lack
It’s a point better perhaps discussed at the dev chat? I raised an agenda topic along thses line as I know from experience if aspects like this are ignored for too long they never get dealt with – yes we have all written comments such /* ought to be improved */ or /* stop gap until better method found*/ and /* ought to be moved to…*/ I still come across them in work I and collegues have written and wince . In BP core files there are comments along the lines of /* must remove markup */ and indeed there is too much markup dotted around core files.
@nuprn1 thanks I’ll take a look at winmerge, sort of feel I’m missing a better way of using SVN but as I’ve said it’s been a while since I’ve used it and Tortoise and trying to get my head around it’s confusing series of commands is a lot of trial and error – no I’m I’m not about to rtfm
@JJJ
Is it July 29 already ?
time is flying by……😆 Fixed zebras. Don’t ask.
I think a thanks is in order to JohnJames for sterling and grueling work in getting 1.2.5 ready and for facing down that rabid pack of zebras
@johnjamesjacoby: i’ve update my bp installation and updated the translation with the latest pot but for blog posts and group updates i see all in english, any idea to fix this?
@nuprn1 Most of my plugins will have that issue, so they will need an update for 1.2.5 also. :sigh: haha
@erich73 Fixed thanks
@hnla @jeffsayre almost had me hunting giraffes. That would have been bad because they’re too cute to hunt.
I utterly refuse to use the phrase ‘Zebra Striping’ again; from now on I have decided it’s ‘Tiger Striping’ yeah and lets leave the poor giraffes alone.
I’m removing the alternating highlighting from the Privacy Component for the time being. The “fix” still has issues. It still selects for the entire form and not per table. If you add another row to the outputted settings tables in the Activity, Messages, or Friends form coding, you will see the issue when navigating to “Settings > Notifications” in your user profile menu.
It is an issue of odd versus even rows in a given table. Right now, since all the outputted tables (a total of four tables are outputted to make up the aforementioned screen) each have an even number of rows, it appears that all works fine. But by doing what I suggest–adding a test odd row–you will see the problem.
Keep it quiet from JJJ as it just might be the straw that breaks the camels back… hmm camels don’t have stripes do they?
sorry finding this subject hard to take seriously now, striping, should be the simplest thing!
See the two new screenshots uploaded to https://trac.buddypress.org/ticket/2465#comment:15
@hnla — I agree. Unfortunately, IE 7 and 8 do not support the simple JQuery fix. However, IE 9 is finally with the program on this issue. But, there are other ways to strip a skunk.
Again, why are we using that JQuery selector with CSS to implement stripes… rather than just using the CSS?
Okay, see my most recent post in that Trac ticket. I’ve discovered that :nth-child selector is not recognized by IE 7/8 when used in CSS but it does work in those IE versions when used via JQuery. So, my proposed fix should work like a charm.
@johnjamesjacoby et al; OMG NO! I just very carefully installed BP 1.2.5 locally on xampp; perfect. I did the same, very carefully, on my server. Now the site works, but ALL of my log-ins are dead, and it won’t send me an emergency log-in by email because it doesn’t recognise a darned thing!
@DJPaul –
Because, as you state in the Trac ticket thread, IE 7/8 does not support the :nth-child selector in CSS. But it will work when it’s used in JQuery. It is a simple, single line fix — at least for the alternate table row highlighting.
@lincme –
I would suggest starting a new thread as your issue will more than likely get lost in this too-long-of-a thread. This thread was really a call to test the pre-release branch version of BP 1.2.5.
I do prefer CSS only as well as even dumb guys like myself are able to change CSS.
@jeffsayre; I’m too cheesed off and tired to bother right now. Installing the latest BP locked me out of WP somehow, and even creating a new MD5 password and resetting it via phpMyAdmin isn’t getting me back in. Disabling BP by removing the folder gives me the white screen of death. I swear, I’m close to saying to people, “You want to talk online? Go use blogger.com and leave me be!”
That guide is pretty much what I have used, haven’t really had to consult a guide though in quite a while for this sort of thing. The point of jQuery and cross browser issues is that the library silently resolves them thus using :nth-child as a straight CSS3 pseudo class will not work for IE but using it within the selector group in a jQuery object and the library corrects for the IE deficiency, or at least thats the way I understood it and one of the reasons amongst many I started to use the library over plain vanilla JavaScript?.
N.B of course I may have got that badly wrong as those of us that have had to struggle through years of IE 5.5 / 6 and the workarounds have tended to avoid CSS3 advanced selectors; would have to test this really.
Tried a few test in IE6 and can’t get any class tokens added, scripting is running but IE refusing to play ball with even basic add class to some other element, the hover function works, so at a loss for the moment.
Edit/ was writing this to the ticket but couldn’t post it ? see you have covered my initial point about jQuery and it’s usefulness where advanced selectors are concerned.
Just want to thank everyone for their hard work getting 1.2.5 out.
- The topic ‘BuddyPress 1.2.5 tickets are cleared out’ is closed to new replies.