[SOLVED] Installation WP 3.0.4 Atahualpa 3.6.4
Scenario: creating, designing, developing, a brand new, first time user, website installation:
> WP 3.0.4 > Atahualpa 3.6.4 theme What, if any, "Fixes" ought to be applied, following brand new stand alone installation of ATA 3.6.4. Many thanks. |
check the 'New Version & Updates' forum
|
Quote:
I thought this was the New Version & Updates :confused: My question is with regard to a brand new (or as in scenario - first user) installation of Atahualpa, i.e. would not be updating, would simply download Atahualpa 3.6.4 upon WP 3.0.4. What would be required? Grateful thanks. |
sorry, I wasn't looking at the forum this was in., Actually at this moment, (Feb 7, 2011) there are no bugfix's for 3.4.6
|
Quote:
so that being the case ... all should be well with brand new installation of 3.6.4 ... i.e. no issues with CSS Stylesheet ?? The reason I ask is due to my concern having looked at View > Page Source ... excerpt as follows: <style type="text/css">/* ------------------------------------------------------------------ ---------- BASE LAYOUT ---------------------------------------------- ------------------------------------------------------------------ */ body { text-align: center; /* centering the page container, text-align will be reset to left inside the container */ margin: 0; padding: 0; font-family: verdana, arial, sans-serif; font-size: 13px; line-height: 1.4; color: #000000; background: #d5d5d5; padding-top: 20px; padding-bottom: 20px; } a:link, a:visited, a:active { color: #365DA0; font-weight: bold; text-decoration: none; } a:hover { color: #365DA0; font-weight: bold; text-decoration: underline; } ul, ol, dl, p, h1, h2, h3, h4, h5, h6 { margin-top: 10px; margin-bottom: 10px; padding-top: 0; padding-bottom: 0; } /* remove margins on sub-lists */ ul ul, ul ol, ol ul, ol ol { margin-top: 0; margin-bottom: 0; } html:/* */not([lang*=""]) div.rMenu-center ul.rMenu li a:hover { height: auto; /* reset for Netscape 7 and better */ } /************************************************** ***************************** * HACKS : Suckerfish w/Form Field Support (for IE 5.5 & 6.x) * * IE6 and earlier do not support the :hover pseudoclass and so javascript is * used to add the "sfhover" class of any LI element that the mouse is currently * over. This method is called suckerfish and you can read up on it at: * http://www.htmldog.com/articles/suckerfish/dropdowns/ * * One problem with this approach is IE6 and earlier versions have a bug where * form fields appear over the dropdown menus regardless of z-index values. * The fix is to generate and stick an IFRAME element under the dropdown menus * as they pop. The JavaScript used to do this requires that we hide menus off * to the side of the screen ( left: -100000px; ), but normal rMenu operation * is to hide menus with the DISPLAY property ( display: none; ). So also * included in the set of rules below are rules to overwrite this original * functionality of rMenu and utilize the LEFT property to move menus off- * screen until needed. Any other rules that use the LEFT property in the * normal rMenu system will also have to be ovewriten here as well. This * includes the dropdown positions. * * NOTE: this allows for support of dropdown menus up to 3 levels deep. if you * want to support greather menu depth you need to alter these selectors. * read the above mentioned website for more info on how to do that. * * The fix to get dropdowns to appear over form fields requires we * position menus off screen rather than simply hiding them with * display:none. So you might think we should not be using the display * property in the fields below. However we can because these display * properties are only being set when a parent LI is being hovered, so * the JavaScript used to operate on these LIs will already have the * dimensions they need before these display rules are activated. */ * html ul.rMenu ul { display: block; position: absolute; /* ovewrite original functionality of hiding element so we can hide these off screen */ } * html ul.rMenu ul, * html ul.rMenu-hor ul, * html ul.sub-menu ul, * html ul.rMenu-ver ul, * html ul.rMenu-vRight ul, * html ul.rMenu-hRight ul.sub-menu ul, * html ul.rMenu-hRight ul.rMenu-ver ul, * html ul.rMenu-hRight ul |
I am unaware of any issues besides the suhosin issue
|
FYI, that code has been there since at lease 3.4.4
|
Quote:
Hi Juggledad, Not displayed as per View > Page Source and definitely not as per 3.5.3. that's why I am asking the question. Many thanks. |
I not sure what you are saying/asking.
Are you saying that that is all you see when you view the source of a page? |
Quote:
Please see Post #5 above. Many thanks. |
Does the host have suhosin installed as part of php?
Is this the same site you sent me the link to? |
Quote:
Yes, this is the same site that I sent the link to. Many thanks. |
when I view that site and look at the source, I see ALL the CSS. Have you made changes to any of the theme code?
|
Quote:
I have not made any changes to the theme code, never have done at any time. And with a brand new install of WP 3.0.4 (now 3.0.5) with ATA 3.6.4 then I Viewed the Page Source code and could see ALL the CSS. Many thanks. |
You have always been able to see the CSS, it is a theme option. Go look at ATO->Configure CSS & JS->CSS: External file or inline? - the default is, and has always been Internal.
|
Not all the stylesheet comments and directives, truly, I have never seen the likes of this before. Please refer back to Post #5.
And certainly not as such with ATA 3.5.3 and prior. With all prior versions I have always looked at View > Page Source and monitored accordingly. Quote:
BTW, there is no Internal, as per your post...what do you mean to say, what is, and has always been ? Many thanks. |
Quote:
Yes this css has ALWAYS been there, go back and install 3.5.3 and then look at the source of the page and you will see all this css. The Atahualpa CSS is in the order of 2700 lines, there are over 400 lines dealing with menu styling itself Mater of fact If you were to go back to 3.4.4 you would still see all this CSS. |
I accept that Juggledad, and was really only asking the question with regard to that of which I had excerpted on and in previous post above - Post #5.
I now see what this issue actually is all about! Happily, I have now resolved this question, and shall mark it well! :) |
For anyone reading the thread, changed the option 'CSS: Compress?' to 'Yes' which removes any comment lines n the CSS and changes the appearance of the CSS since it is now 'compressed'.
|
Quote:
For anyone reading this thread, this assumption is truly not so, simply because I had already had CSS: Compress set to 'Yes' Please see my other thread, which explains the issue with all the comments and directives in the CSS. http://forum.bytesforall.com/showthread.php?t=12657 Many thanks. |
Thank you for point outthe case in which the error happens. I looked at the code and in the 3.6 release, there was a change that causes the compression to be ignored if 'Allow debugging' is set to 'Yes'.
I have created a BUGFIX, see http://forum.bytesforall.com/showthread.php?t=12685 |
All times are GMT -6. The time now is 01:54 PM. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.