CUNY Academic Commons

That's probably the jQuery. The CSS would be cached and probably is not being reloaded/reset by some browsers. I don't have a Mac to work with, so this may take some trial and error.

Yeah, but it was only happening with about half the slides. So out of 8 slides, 1-4 would hide the nav buttons, even on the second and third times through the rotation on a single page load.

Again, this is not so much an issue on the Commons anymore, as I put a fix in our stylesheet. I just wanted to bring it to your attention. It's possible that it's being caused by some funky styles in the Commons theme, but the fact that it was only happening with a select number of slides makes me question whether it could have been caused by our CSS alone - there must be something different in the markup, though I studied it for about 10 minutes and couldn't find anything.

I installed the Firefox beta earlier this week and it just occurred to me to see if this happened with FF 4 (for linux) and it does. So, it may be less trouble to track this down than I was expecting.

It turned out when we looked at our site that was using it that the prev/next did not appear at all.

The cause of that was if any of the wrapper containers have a float on them the absolute positioning of the prev/next were relative to the body rather than the gallery widget.

I've redone the widget with some changes in the CSS file and applying styles in the widget HTML. The widget control now has width & height settings. It's checked into the dev version of the repo at wordpress.org.

@Boone - Do you want me to try to update the home theme or do you think it would easier/quicker if you did that?

Nice detective work, Ron. Thanks!

Hey Ron - Cool, please do update the home theme accordingly. I threw the added styles at the bottom wp-content/themes/bp-nelo/_inc/css/custom.css, under the Post Gallery Widget heading.

I'll see what I can do over the weekend.

Just checked in an update that works fine in FF 4 (linux version). Some notes

- once you move that to the dev site you need to set the width/height in the widget control to 590/335
- the prev/next links are in the output of the widget. I removed them from the theme
- the slideshow div is also output by the widget. I removed it from the theme. This was one of the original problems from a CSS perspective because CSS from the PGW was applying to this div as well as the one nested inside it

Sounds great, Ron. Can you push those changes to Github so I can see them?

They should be in master.

Hm... I don't see them in the commit log https://github.com/castiron/cac/commits/master

discovered I had an error on push:

To git@github.com:castiron/cac.git
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'git@github.com:castiron/cac.git'

Is that due to a conflict?

Yes, it means that people (me :) ) have pushed to the shared repo since you last pulled. Conflict resolution has to happen locally, so you'll need to
git pull origin master
before pushing back.

It should merge cleanly, but if it doesn't and you get conflict messages, use
git mergetool
to figure them out. Then git add . and git push.

That's in. What did I do here: https://github.com/castiron/cac/commit/9a6bd2a710316254a21eba59efafc7c3fe2235f2 ?

The merge refused to cooperate in that the mergetool said there was nothing to merge.

Hm. Why did you revert that commit? (In this case it doesn't matter much, as I wanted to remove that wiki2latex plugin anyway!) And I still don't see the changes to Post Gallery Widget. Unless I'm missing something?

Surefire method:
git pull origin master
make your changes
git commit -am "Made my changes to PGW"
git pull origin master #just to be safe
git push origin master

I was trying to do the equivalent of an 'svn revert'. The only way I knew I had done that commit was I was looking at the log on github.

For whatever reason, I couldn't push due to the conflict on custom.css. Whenever I pulled it told me custom.css was out of date. But, mergetool kept saying there was no conflicts to resolve.

Could you try a pull with rebase, to see if it will fix itself?

git pull --rebase origin master

"refusing to pull with rebase: your working tree is not up-to-date"

It sounds like you might have uncommitted changes in your working tree. When you do
git status
it should any changes waiting to be staged. If it does, either commit them, or
git stash
which will remove all uncommitted changes and stash them; after syncing back up with the remote, you can reapply them with
git stash pop

In the course of sorting that out I realized where I went wrong. I forgot the -a on the original git commit.

Looks awesome - thanks, Ron!

In your local version try removing (or commenting out)

.introbox span {
margin-left: -593px;
}

from the ie.css & see if that fixes it for you. I'm not sure which line that's on.

Just as an additional note. That worked for IE8 but I don't have IE7 (or 9) to work with.

Boone Gorges wrote:

Ray, this is an IE styling issue for the front-page slider. Will you have a look? (No need to read the whole history of the ticket if you don't want to - just have a look at Ron's suggestion)

Alright! First ticket!

I checked the live site and my local copy of 1.1-branch and I do not experience the margin-left offset problem in the screenshot Boone attached. However, I did experience the bug on cdev.gc.cuny.edu.

Is cdev running 1.1-branch? Boone, I might a refresher on the versioning!

By the way, Ron, to emulate IE7 mode in IE8, just hit the "Compatibility View" button and it should render the page using IE7 standards.

My bad! I forgot to sync my branch with the master! :(

Ron's suggestion works for IE8, but breaks for IE7.

I can fix it with either valid or invalid CSS hacks.

Valid:

/* target IE7 */
*:first-child+html .introbox span {margin-left:-593px;}

/* target IE6 */
* html .introbox span {margin-left:-593px;}

Invalid:

/* targets IE7 and below */
.introbox span {*margin-left: -593px;}

Valid approach requires duplication of code if we want to support IE6.

Let me know which method you prefer.

I suggested removing that CSS vs adding it.

it's already in ie.css and when I removed it, the gallery widget was fine in IE8.

"By the way, Ron, to emulate IE7 mode in IE8, just hit the "Compatibility View" button and it should render the page using IE7 standards."

I think I've used IE8 all of 3 times, this being one of them :D

Ron Rennick wrote:

I suggested removing that CSS vs adding it.

it's already in ie.css and when I removed it, the gallery widget was fine in IE8.

Yeah, but removing that bit of CSS breaks the layout in IE7 / 6.

Re: http://redmine.gc.cuny.edu/issues/show/526#note-23

Fixes IE7/6 margin-left offset using invalid CSS hack:
https://github.com/castiron/cac/commit/ec72020aeb5b62a39c6d66be91b6d54252f026e8

Boone, let me know if I'm doing things right!