Bug #526
closedNext/Previous Links Don't Appear on All Hero Slides
100%
Description
When I load the homepage on Mac OS/Chrome + FF, I find that the next/previous links on the hero slides don't appear until about the third slide in. It might very well be that they are not appearing on slides that were created after our 1.1 site upgrade (that's definitely true for the year-end slide; not sure about the Codex slide).
Files
Related issues
Updated by Boone Gorges over 13 years ago
- Status changed from Assigned to Resolved
All of the slides were created after the 1.1 upgrade; that's when we installed Ron's widget.
Ron, for some reason, the z-index on some of the slides was too high. I forced the z-index of #pgw-prev and #pgw-next to 20 (with !important to make sure that they don't get set back to 5 when the plugin stylesheet loads) in our stylesheet. Not sure if this is an issue with the plugin or not - I suck at z-index issues.
Fixed in https://github.com/castiron/cac/commit/1901a1f0fbc381b717c06f7233868554020be662
Updated by Ron Rennick over 13 years ago
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.
Updated by Boone Gorges over 13 years ago
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.
Updated by Ron Rennick over 13 years ago
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.
Updated by Ron Rennick over 13 years ago
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?
Updated by Boone Gorges over 13 years ago
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.
Updated by Ron Rennick over 13 years ago
I'll see what I can do over the weekend.
Updated by Ron Rennick over 13 years ago
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
Updated by Boone Gorges over 13 years ago
Sounds great, Ron. Can you push those changes to Github so I can see them?
Updated by Boone Gorges over 13 years ago
Hm... I don't see them in the commit log https://github.com/castiron/cac/commits/master
Updated by Ron Rennick over 13 years ago
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?
Updated by Boone Gorges over 13 years ago
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.
Updated by Ron Rennick over 13 years ago
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.
Updated by Boone Gorges over 13 years ago
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
Updated by Ron Rennick over 13 years ago
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.
Updated by Boone Gorges over 13 years ago
Could you try a pull with rebase, to see if it will fix itself?
git pull --rebase origin master
Updated by Ron Rennick over 13 years ago
"refusing to pull with rebase: your working tree is not up-to-date"
Updated by Boone Gorges over 13 years ago
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
Updated by Ron Rennick over 13 years ago
In the course of sorting that out I realized where I went wrong. I forgot the -a on the original git commit.
Updated by Boone Gorges over 13 years ago
- File pgw.tiff pgw.tiff added
- Status changed from Resolved to Assigned
- Assignee changed from Boone Gorges to Ron Rennick
- Target version changed from 1.1.7 to 1.2
Hey Ron - sorry to open this one again, but after pulling the most recent PGW changes to cdev, the widget display isn't looking right in IE8. (I've attached a screenshot.) Can you have a look when you get a chance?
Updated by Ron Rennick over 13 years ago
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.
Updated by Boone Gorges over 13 years ago
- Assignee changed from Ron Rennick to Raymond Hoh
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)
Updated by Ron Rennick over 13 years ago
Just as an additional note. That worked for IE8 but I don't have IE7 (or 9) to work with.
Updated by Raymond Hoh over 13 years ago
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.
Updated by Raymond Hoh over 13 years ago
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.
Updated by Ron Rennick over 13 years ago
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.
Updated by Ron Rennick over 13 years ago
"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
Updated by Raymond Hoh over 13 years ago
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.
Updated by Boone Gorges over 13 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
Applied in changeset commit:"1901a1f0fbc381b717c06f7233868554020be662".
Updated by Raymond Hoh over 13 years ago
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!