CSS nav - GoDaddy and preview DNS

Don’t blame everything on GoDaddy! I am not a great fan but facts need to be right before blaming someone who may not be at error.

On Mar 23, 2013, at 6:32 PM, Caleb Grove wrote:

Is it really a Softpress issue? or a GD one.

Godaddy, but yet it could be very easily circumnavigated by Softpress by an update to the CSS menu action. I don’t think we will see GoDaddy fixing this anytime soon.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Well I can’t get Tim’s Externalize action to work for me. I’m deleting the site now and I’m going to upload a fresh copy.

What I don’t understand is why GoDaddy accepts the very same CSS menu code on the Perch enabled pages, but not the standard pages. There must be something else at work here that we’re missing.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Here’s a quickie Action that will fix this one thing. Please note: this is a destructive Action – it will rewrite all of the HEAD tag to plain text, rendering it un-readable to other Actions. It runs at fwAfterEndHTML, which is the very last slot in the Action callback hierarchy, so hopefully this won’t be a big issue, inter-Action-cooperation-wise.

http://actionsforge.com/actions/view/296-godaddyhelper

Apply this Action to the pages that also use the CSS Menus, and you should be all set.

Hopefully Softpress will fix the CSS Menus Action so it doesn’t do this any more, too.

Walter

On Mar 23, 2013, at 1:53 PM, RavenManiac wrote:

Well I can’t get Tim’s Externalize action to work for me. I’m deleting the site now and I’m going to upload a fresh copy.

What I don’t understand is why GoDaddy accepts the very same CSS menu code on the Perch enabled pages, but not the standard pages. There must be something else at work here that we’re missing.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Wow! That’s very kind Walter. Thank you.

A few questions. In Document Setup I selected use External Stylesheets. Does that mean that all CSS Menus are by default internalized within the HTML page?

If use this action what happens to my Perch enabled pages, which require a runtime call in the Before Head tag?


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

On Mar 23, 2013, at 2:59 PM, RavenManiac wrote:

Wow! That’s very kind Walter. Thank you.

A few questions. In Document Setup I selected use External Stylesheets. Does that mean that all CSS Menus are by default internalized within the HTML page?

Yes, the current version of CSS Menus stores the stylesheets for each page’s menu(s) in the page head. I wrote a library of code that allows these to be moved out to an external sheet, but it came too late in the development process for Softpress to implement it. (And I wrote it out of frustration with the current state of the CSS part of the Actions API. My dream is that something far more integrated is added to the Actions API, not that Softpress uses my code to move their Actions’ CSS to external files.)

If use this action what happens to my Perch enabled pages, which require a runtime call in the Before Head tag?

You don’t need this Action there – as you have noticed, they don’t get parsed by Apache. Any PHP files are handed off to the PHP interpreter by Apache, and no further notice is taken of any SSI include-looking code in their page head or elsewhere.

Walter


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

So will the action also destroy special HTML Head formatting code like this?


<!-- Begin Menu drop shadow code -->
<style type="text/css">
.sub {
-webkit-box-shadow: #000000 3px 3px 5px;
-moz-box-shadow: #000000 3px 3px 5px;
box-shadow: #000000 3px 3px 5px;
}
ul.sub, ul.sub li.fwLastChild, ul.sub li.fwLastChild a {
-webkit-border-bottom-right-radius: 5px;
-webkit-border-bottom-left-radius: 5px;
-moz-border-radius-bottomright: 5px;
-moz-border-radius-bottomleft: 5px;
border-bottom-right-radius: 5px;
border-bottom-left-radius: 5px;
}
</style>
<!-- End Menu drop shadow code -->

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Try it. I can’t imagine it will, but here’s exactly what it does:

  1. Gets a reference to the HEAD tag.
  2. Wraps that tag in another HEAD tag.
  3. Goes through each element contained in the original HEAD tag, converts it to HTML, runs a regular expression replacement on it to change all instances of <!–# to <!-- #.
  4. Writes each resulting text block into the new HEAD tag.
  5. Deletes the original HEAD tag.

It’s a very targeted and precise tool, but it is destructive. There’s probably another way to write this, but I don’t know what it is off the top of my head. Tim might be able to improve on it. He’s a member of the project already so he can alter it at will.

Walter

On Mar 23, 2013, at 3:27 PM, RavenManiac wrote:

So will the action also destroy special HTML Head formatting code like this?


<!-- Begin Menu drop shadow code -->
<style type="text/css">
.sub {
-webkit-box-shadow: #000000 3px 3px 5px;
-moz-box-shadow: #000000 3px 3px 5px;
box-shadow: #000000 3px 3px 5px;
}
ul.sub, ul.sub li.fwLastChild, ul.sub li.fwLastChild a {
-webkit-border-bottom-right-radius: 5px;
-webkit-border-bottom-left-radius: 5px;
-moz-border-radius-bottomright: 5px;
-moz-border-radius-bottomleft: 5px;
border-bottom-right-radius: 5px;
border-bottom-left-radius: 5px;
}
</style>
<!-- End Menu drop shadow code -->

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options