[@hnla Participant 16 years ago]

Then have you adjusted the min/max widths in adminbar.css?

[@hnla Participant 16 years ago]

try, rather than using !important, removing/ changing the offending ruleset in default. If you have copied default over to your child theme you are better of removing / adjusting styles in it than overriding. If you drop back to using default theme it will pick up the original styles.

[@hnla Participant 16 years ago]

You’re probably being foxed by this naughty little ruleset in default.css
`
line 60
#wp-admin-bar .padder {
width:90% !important;
}
`

[@hnla Participant 16 years ago]

The new menus have oversights, out of interest do we know what if any changes may be implemented for nav menus in 3.1 if there are it would make sense to add that patch to the mix for testing – given that 1.3 will release after 3.1?

[@hnla Participant 16 years ago]

Patch added: https://trac.buddypress.org/ticket/2691

[@hnla Participant 16 years ago]

I can try haven’t used Tortoise to create patch before. You agree though, on the depth param?

[@hnla Participant 16 years ago]

Well logic would dictate to some extent simply replicating the adminbar styling more or less.

the opportunity should be taken though of getting rid of the graphics and replacing them with versions that aren’t 1×1 and if adding hover it should also be matched with :focus

[@hnla Participant 16 years ago]

Not sure of the point in posting these comments on this support site really, think you really need to direct these to the authors site, if you’re post has been deleted inquire privately of them as to why

[@hnla Participant 16 years ago]

Had intended on looking in detail at new menu arrangement but have had a really problematic time running 1.3 on a clean relatively fresh and mainly unused WP 3.0.1, not sure what the issues are at this moment but not feeling the love for these new page approaches to the main components as they hang around – obviously – despite reverting to 1.2.6.

[@hnla Participant 16 years ago]

no ‘display:none;’ please, left:-999em; / left:0;

What are intending on doing for users having to still use IE6 ?

[@hnla Participant 16 years ago]

edit// ok scrub that modemlooper has sorted it.
I’ll take a look in the morning, the new menus have a draw back at the moment in not doing nested dropdowms so not sure how you’ve forced that behavior, I implemented them in pcwriters plugin using a top level li element as exists for adminbar elements.

[@hnla Participant 16 years ago]

To go about doing this would require fairly advanced PHP skills and experience with the BP API, it’s not a straightforward task. Not sure if anyone has attempted this, think it’s been discussed or touched upon briefly before

Not sure this does make sense though would it not result in possibly a very bloated xprofield table full of user created one off custom fields.

[@hnla Participant 16 years ago]

If you can’t upload files to BP album that is the same issue as if I’m not mistaken it uses the WP mechanism for uploads, and in fact this suggests a test that ought to be run to see if WP is able to upload files, so with BP deactivated try running the site as plain WP and see if uploads are possible.

As for uploading new 1.2.6 yes general approach is deactivate all bp related plugins, safer to remove bp plugin directories but you could try simply overwritting (I often do, generally it’s ok) then reactivate BP establish it’s running ok and then reactivate other bp plugins

[@hnla Participant 16 years ago]

You might try re-uploading the 1.2.6 files but via FTP this time and see if that makes a difference -failing that you may need to roll back to 1.2.5.2

[@hnla Participant 16 years ago]

It would be more like this:

if (bp_get_profile_field_data(‘field=thefield’) == ‘string’) :

[@hnla Participant 16 years ago]

Covered quite often on the support form; standard answer is to rename the plugin via FTP or SSH , this will force deactivate the plugin and should allow you access again. Likely reason for this happening? Too low a PHP script memory limit.

[@hnla Participant 16 years ago]

Maybe it isn’t a server issue then but it’s difficult to suggest what else may be the issue. I have updated three separate installs to 1.2.6 recently in production environments and have not experienced this issue.

One thing that I do avoid is ever using the autoupdater as I believe this can cause issues with server permissions and don’t trust it generally, I only transfer updates via FTP.

You might need to contact your server support and ask them if they can check user and group permissions as I mentioned earlier, doing this while checking other possibilities might be wise?

[@hnla Participant 16 years ago]

Can you rule out some of the things I mentioned, after that you might need to approach your server admin and ask if they can check user/group permissions, explaining exactly the issue.

[@hnla Participant 16 years ago]

That you cannot upload points more to an issue with server permissions than BP; even with folder permissions set to 777 the right group permissions need to be in place for the server to be allowed to move files around.

Are you sure no other changes were made to the server? nothing like PHP safe mode turned on, are you on a shared host or do you control the server yourself? What have you tried if anything to rectify the issue? probably won’t help but doesn’t hurt to visit the permalinks page just to ensure you flush possible cache, reset those folder permissions, check who the owner of the directories is, ftp, server or the dreaded pcaln.

It’s also probably worth just ensuring this isn’t a plugin issue by disabling all but absolute required and dropping back to default theme.

I don’t think these points will help all that much, but you need to test a few things and rule them out for us. hopefully someone else may have encountered the same issue (I’ve uploaded 1.2.6 twice to production and not had the issue)

Also how did you upgrade? upload via FTP or using the automatic upgrade?

[@hnla Participant 16 years ago]

Think we just need to wait on a decision as to whether a bug fix point release is agreed, obviously from our point of view it’s an easy core hack to implement.

[@hnla Participant 16 years ago]

Themes more obviously break things, they are for more obvious if they perform badly, and reflect that much more on WP as a whole would be my guess. I’ve always been of the opinion that they really ought to be vetting plugins as a badly written plugin could have far more serious consequences it would be nice to see a two tier repository where there were approved /recommended /tested plugins and a second general pool but it’s probably a lot of work.

It had crossed my mind to mention the lack of comment tag in pages but sort of thought that it might have been for a reason and that I’d be pointing out the obvious.

[@hnla Participant 16 years ago]

Darn it I could have added that ages ago is this really the first time it’s been noticed

[@hnla Participant 16 years ago]

Isn’t the simple answer to copy across page.php fix up and submit? they are testing the child theme after all, it will perform as expected then, it may defeat the purpose of a child theme but fixes the issue from your perspective?

[@hnla Participant 16 years ago]

That was belief as well, only appears to backup wp prefix tables and they do mention not being able to back up BP at this time, I think they may intend to when the basic service is bedded in fully.

[@hnla Participant 16 years ago]

The reason this is happening is due to the child elements being floated and following proscribed behavior,escaping their parents boundaries, the li item height is less than it’s floated child element thus the li elements can’t float fully to the left as the child element drops below each list bottom edge.

Clearing solves this but also containing floats does and ensures that the parent is forced to extend it’s boundaries to include the floats using ‘overflow:hidden;’