I just updated my site to include the most recent Dev version of Rotor, and have come across what I believe to be a potential CSS style change issue from the previous DEV I was using (2009-Dec-03). The CSS code that was added since that dev version is included below:
.views-field-field-test-image-fid,
.field-content,
.views-row {
line-height: 0;
}
I am very certain this CSS code was meant to help address an issue with extraneous padding being added to the display images uploaded into the Rotor content type (or custom content-types utilizing the rotor style plugin which you have helped me with before).
It essentially caused a few of my sites with custom views blocks to collapse/overlay their field displays on top of one another. I noticed this effect for at least the blocks that were styled as Unformatted or Rotor. The block example pictures below were a block that encountered this issue. The block was an unformatted style, and included several fields displaying text, and were not tied to a custom view that included any Rotor based styling.
The same issue also occurred on a development site using a custom content type with the style of rotor that included an image and a small text-field. The image displays fine, but all text was overlaid on top of each other.
For now, I have found commenting out that newest addition off the CSS style above has solved the issue for me. Not knowing exactly how this might affect others, I wanted to give you a heads up. Since I am not using the included rotor content type, I don't know if a change to the above css would achieve the same effect or not:
.views-row .views-field-field-test-image-fid .field-content
{
line-height: 0;
}
Please let me know if I can be of any more assistance with this "issue". I realize I might be the minority encountering this. I'm runnning the latest Views (6.x-2.10) as well, but I repeat this issue on the previous version of Views 6.x-2.8 as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | blockdisplaybefore.jpg | 59.46 KB | GatorBat |
| #1 | blockdisplayafter.jpg | 38.78 KB | GatorBat |
Comments
Comment #1
GatorBat commentedComment #2
silkyD commentedThanks for the heads up. Commenting this out this section of code worked wonders.
Comment #3
TheInspector commentedThis issue remains in the stable 6.x-2.5
Comment #4
seanrThis is really screwing with our sites, causing all kinds of font issues on our sites' home pages. Why in the world would you include CSS for one module that is so broad and destructive? It's a royal pain to override in theme css - we had to strip the line out of your CSS to get our sites back to normal. Never include CSS without explicitly limiting it to classes used only by rotor. Marked critical since this really messes with themes.
Comment #5
mrfelton commentedThis should be resolved - I have removed the offending code (in CVS). It was never supposed to be committed in the first place, but was a hack for the problem described in #625526: Provide an option in the Rotor Style Options to fill up a block/region
Comment #6
royerd commentedIt is not fixed. It's in the stable 6.25 version. I had to hunt this CSS problem down. It screwed up my views using HTML lists.
I guess I don't know the protocol on this. Do you leave it in the stable version until the DEV version becomes the new stable version? It would seem that there are a lot of people out there trying to figure out why their views HTML lists are displaying with zero line height. Are they supposed to know to download the dev version? I'm just curious how this works.
Comment #7
mrfelton commentedIt is fixed - in CVS
Comment #8
stompersly commentedAfter having this problem I just tried the latest rotor-6.x-2.x-dev version... which still has problems. I recommend you update the status of the rotor-6.x-2.5 so that it is something other than recommended because it is anything but. I have not figured out what I need to downgrade to to make the problem go away. I even tried commenting out the css line suggested above in the rotor.css file, that helped all the other blocks, but did not solve the problem for the rotor block. Seems like some serious lack of testing on rotor, seems best to disable for now and consider other modules.
Comment #9
mrfelton commentedI committed the change this morning. -dev releases are made every 12 hours, so chances are it has not made it into a -dev tarball yet. Please check out the code from CVS, clear your cache, and confirm if the problem still persists or not.
I did not cut the 6.x-2.5 release. It was done for me by the Drupal Security Team. They did not give me a chance to review.
If you can confirm that the changes that I committed to CVS this morning have fixed the problem, then I will cut a new release.
Comment #10
GatorBat commentedNot to muddy this thread any further, but I wanted to make a small note about thee recent discussion regarding this whole issue, seeing as I started it a while back.
Yes, the Rotor 6.x-2.5 release still contains the code I mentioned will most likely need to be commented out. I upgraded to the 6.x-2.5 stable version a short while ago, and after commenting out the CSS lines from my original post, I cleared my site cache (admin/settings/performance) and cleared my views cache (admin/build/views/tools) - and I am having NO ISSUES with the 6.x-2.5 version. All blocks/content appear perfectly normal and as expected, whether or not they are styled with the Rotor plug-in in views related content. Keep in mind, I am NOT USING the default rotor content type MrFelton provides, I am using my own custom CCK types with Rotor assigned as the style.
I did also try the latest dev release now posted on May 21, 2010. While the offending CSS code has indeed been removed, I noticed one additional line had been removed that may or not impact things (I could not find how it impacted my current use of Rotor styling on blocks and such on my custom CCK types).
Current/Previous builds (including 6.x-2.5) contain this CSS code in rotor.css:
The dev build Rotor 6.x-2.x-dev (2010-May-21) removes code that started this entire post, and also removes the line-height line shown above:
I had my own issues with 6.x-2.x-dev (2010-May-21) in that NONE of my custom CCK types would actually rotate through their content, despite running update.php again, and clearing site cache and views cache. I didn't delve into it much further before applying the stable 6.x-2.5 version. If I get some more time to test it out, and still encounter this issue, I'll open a new ticket :)
On a side note, #8, I understand the frustration, I truly do, but I can tell you I've tried several other modules of this type before, and haven't found anything close to the level of flexibility that Rotor provides. I've also found MrFelton to be very responsive in helping me solve my own bugs, and even committing a couple of suggestions I've made into this module as his time permits. I wouldn't abandon the use of this module, but maybe we can help you out with some more details about the problem.
Comment #11
seanrSince this is still in 6.x-2.5 and drush gets latest tagged releases not dev versions unless manually specified, please tag a release at least to fix this bug. We have over 100 web sites that require drush updates which is pulling bad code and forcing us to manually override. Thanks.
Comment #12
mrfelton commentedI have just tagged a new release. Should be out shortly. I hope this remedies the problem.
Comment #13
dekan commentedShould everything just work 'out of the box' as before? I just updated my rotor module, but all rotos views I have on my page won't cycle through anymore. The first image/text/link (depending on what I have in there) just stays...
thanks!
Comment #14
mrfelton commentedI can only apologies, please upgrade to 6.x-2.7 (just released).
Comment #15
dekan commentedPerfect. Updated to 2.7 and it works no problem. Thanks so much! :-)
Comment #16
JGO commentedI think something changed lately.
I have this problem:
I have a rotor with 3 nodes. When the page loads now you clearly see at first that there are 3 nodes.
It takes a while before the javascript loads and only shows the current node.
In the past this took less time or at least it was never visible. I have this since updating from 6.x-2.5 to 6.x-2.7
This problem is clearly visible in IE and less visible in chrome (because chrome is faster anyway), but like I said in the past I never saw this with IE either.
With 6.x-2.6 the non-current where not hidden at all (because of the bug fixed in 2.7), so I think has to do with the latest changes.