Just updated a site using HTTPS CDN Helper to use SSL. However, there’s a problem or a possible bug?
On certain pages in subfolders, something (the action?) changes CSS file links from…
<link rel=stylesheet href="../css/index4.css">
to
<link rel=stylesheet href="../css/profile.css">
Where profile.css is the page files name and yet the CSS file does not exist. It should be index4.css.
I’ve not quite got to the bottom of why, however, there’s four subfolders and random from each are affected. If I knew the reason why Freeway named CSS files index1.css to index4css. Any why some subfolder pages keep using those sheets. I’m sure the answer is there.
Any ideas?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I’ll take a look at that. That’s entirely surprising to me, because there’s nothing in the Action that renames files like that. All it does is locate any link or script tags on the page, convert their HREF attribute to a string, and do a regular expression find-and-replace for http: to https:.
Walter
On Feb 12, 2018, at 12:53 PM, David Owen email@hidden wrote:
One for Walter…
Just updated a site using HTTPS CDN Helper to use SSL. However, there’s a problem or a possible bug?
On certain pages in subfolders, something (the action?) changes CSS file links from…
<link rel=stylesheet href="../css/index4.css">
to
<link rel=stylesheet href="../css/profile.css">
Where profile.css is the page files name and yet the CSS file does not exist. It should be index4.css.
I’ve not quite got to the bottom of why, however, there’s four subfolders and random from each are affected. If I knew the reason why Freeway named CSS files index1.css to index4css. Any why some subfolder pages keep using those sheets. I’m sure the answer is there.
This project is exclusively templates pages built with a CMS inserted. I can’t think that would be the issue though. I used this with a Freeway 7.1.4 site last month and no issues there. However there were no sub folders on that project.
This site with the problem is an older site on Freeway 6.1.2 (with sub folders) not yet converted to 7. So perhaps thats the issue. I’ll upgrade the file to see if that related at all.
David Owen { Freeway Friendly Web hosting and Domains }
On 12 Feb 2018, at 22:15, Walter Lee Davis email@hidden wrote:
I’ll take a look at that. That’s entirely surprising to me, because there’s nothing in the Action that renames files like that. All it does is locate any link or script tags on the page, convert their HREF attribute to a string, and do a regular expression find-and-replace for http: to https:.
Walter
On Feb 12, 2018, at 12:53 PM, David Owen email@hidden wrote:
One for Walter…
Just updated a site using HTTPS CDN Helper to use SSL. However, there’s a problem or a possible bug?
On certain pages in subfolders, something (the action?) changes CSS file links from…
<link rel=stylesheet href="../css/index4.css">
to
<link rel=stylesheet href="../css/profile.css">
Where profile.css is the page files name and yet the CSS file does not exist. It should be index4.css.
I’ve not quite got to the bottom of why, however, there’s four subfolders and random from each are affected. If I knew the reason why Freeway named CSS files index1.css to index4css. Any why some subfolder pages keep using those sheets. I’m sure the answer is there.
On 12 Feb 2018, at 22:15, Walter Lee Davis email@hidden wrote:
I’ll take a look at that. That’s entirely surprising to me, because there’s nothing in the Action that renames files like that. All it does is locate any link or script tags on the page, convert their HREF attribute to a string, and do a regular expression find-and-replace for http: to https:.
Walter
On Feb 12, 2018, at 12:53 PM, David Owen email@hidden wrote:
One for Walter…
Just updated a site using HTTPS CDN Helper to use SSL. However, there’s a problem or a possible bug?
On certain pages in subfolders, something (the action?) changes CSS file links from…
<link rel=stylesheet href="../css/index4.css">
to
<link rel=stylesheet href="../css/profile.css">
Where profile.css is the page files name and yet the CSS file does not exist. It should be index4.css.
I’ve not quite got to the bottom of why, however, there’s four subfolders and random from each are affected. If I knew the reason why Freeway named CSS files index1.css to index4css. Any why some subfolder pages keep using those sheets. I’m sure the answer is there.
…and to be fair I blanketed the whole site with the action by using the master page when it’s only a couple of pages using some Freeway animation which needs the tickbox. And luckily these are not in a subfolder. But then the problem might not have been spotted.
David Owen { Freeway Friendly Web hosting and Domains }
Can you duplicate this problem in a cut-down site (just one page). See if there are other Actions on the same page that affect this problem. You may find that it is dependent on the order that the other Actions are added to the page. I can guarantee that the problem is not directly with this Action, because this Action doesn’t upload a file to the page.
Walter
On Feb 13, 2018, at 5:09 AM, David Owen email@hidden wrote:
…and to be fair I blanketed the whole site with the action by using the master page when it’s only a couple of pages using some Freeway animation which needs the tickbox. And luckily these are not in a subfolder. But then the problem might not have been spotted.
David Owen { Freeway Friendly Web hosting and Domains }
i have exactly the same problem with CDN Helper when if i active USE HTTPS links…
Do you find a solution ?
In my case the problem exist for master page with the actions (by order):
Favicon 1.4, Auto Clear fix (FW 7) 1.0.3, WebYep 3.5, HTTPS CDN Helper 0.3.1
I’m turning more and more sites into https and the only trick I find is to disable the external stylesheet in Freeway preference but it’s not a good solution !
freewaytalk mailing list
email@hidden
Update your subscriptions at:
There’s nothing about this script that will rewrite a link or script tag if it doesn’t already exist. And if it does exist, and doesn’t have a protocol (http: or https:) in it already, it won’t affect that either. Here’s a link to the code:
Lines 14 and 22 are the only parts that do anything at all. As you can see (JavaScript reads more or less like English, left to right) the Action only changes the literal string http: to https: and performs a very strict replacement of the non-secure Freewaypro CDN address for its secure CloudFront equivalent. If the page has any of those kinds of elements on it at the moment that the Action runs during publishing, they will be replaced.
That caveat is very important. The Freeway Actions API (Application Programming Interface) does not give Action authors any means of ordering or prioritizing the order in which Actions are applied to the page, only the section of the resulting HTML source where the output will occur. When Freeway publishes, it takes a document object model (DOM) written in a very high-level symbolic language and “dumbs it down” to HTML and CSS. That process is a translation, and it happens in a sequence, ordered by the way the output HTML will be written. Actions can call into that process and modify the HTML as it is written and transformed. They can also modify the source DOM as it is being published, and leave behind tags that can then be modified by other Actions. You can see this order in the Page / HTML Markup dialog, if you toggle the picker at the bottom of the dialog:
Before HTML
Before HEAD
Before /HEAD
After /HEAD
Before BODY
After BODY
Before /BODY
After /BODY
Before /HTML
After /HTML
(That’s from memory, and a knowledge of HTML structure, I don’t have Freeway running on any of my Macs at the moment. There may be slight differences to what is actually there.)
If you look at line 9 of the script above, you’ll see that my Action is written to call into the output of the source after all the HTML has been written. But that’s by no means the same thing as “after everything else has run”. Other Actions may also call into that point in the output process, and there’s no way to influence what the actual order of operations will be. I have long suspected that the order is based on the order that the Actions were applied to the page (or inserted into the page flow, in the case of inline Actions). Then there’s the difference between Folder Actions and Page Actions. Both define the same set of callbacks, but it’s not clear to me (and it is not documented anywhere that I know of) whether the Page actions are called before or after the Folder Actions (which are really just a special form of a Page Action, with the shortcut of applying to all pages in the folder they are applied to).
This is all a long-winded way to say that the CDN Helper doesn’t write or generate or rewrite internal (relative) links or script src references. And if it doesn’t seem to work universally, then it may be encountering links or script src references that were hand-written into the Page HTML markup (which it cannot see or change) or it may be missing the output of other Actions that run after it in the publishing process.
Walter
On Dec 9, 2020, at 6:16 AM, Tnapal email@hidden wrote:
Hi Walter,
i have exactly the same problem with CDN Helper when if i active USE HTTPS links…
Do you find a solution ?
In my case the problem exist for master page with the actions (by order):
Favicon 1.4, Auto Clear fix (FW 7) 1.0.3, WebYep 3.5, HTTPS CDN Helper 0.3.1
I’m turning more and more sites into https and the only trick I find is to disable the external stylesheet in Freeway preference but it’s not a good solution !
If the non-https links are being added by Actions, it might be worth seeing if there are updated versions of these Actions:
Otherwise, you could try to find out where the non-https links are being added within your Freeway document. The Edit URLs dialog (available in the Edit menu) should help you to do that.
Jeremy
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I am not a developer and your knowledge in programming Freeway actions exceeds mine.
in fact, when I started to add this action to an https site, it happened as for David Owen, pages based on the same Master page which previously all pointed to the same page css each have a new link that points to a css with the same name as their page name.
And freeway does not create a corresponding css file for each page
something is happening in the software that causes Freeway to change the links for each page but not generate the corresponding css files!
I tried to delete all css but Freeway keeps the same behavior.
When I deactivate the HTTPS CDN action everything returns to order.
So there is a conjunction of factors that creates this dysfunction for pages based on the same master page and with an unmodified layout,
Freeway usually creates a single common css sheet for these pages.
In another site based on a master page but where I modified each layout afterwards, Freeway generates as many css sheets as there are pages, this is its normal behavior and in this case I have no no problem when I use this action.
It is a very mysterious bug for me and i try to explain to you in which case it appears.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
That is baffling to me. I wish I had a working Mac with Freeway on it, I’d like to get to the bottom of this. I have updated all of my “Scripty” Actions to not need this extra helper Action any more, they all use HTTPS by default and don’t bother asking you if you’d prefer anything else. You can put HTTPS resources inside an HTTP page, which doesn’t make the non-secure page secure, but also doesn’t stop the page from loading.
Walter
On Dec 10, 2020, at 1:06 PM, Tnapal email@hidden wrote:
Hi Walter
Thank you for your reply
I am not a developer and your knowledge in programming Freeway actions exceeds mine.
in fact, when I started to add this action to an https site, it happened as for David Owen, pages based on the same Master page which previously all pointed to the same page css each have a new link that points to a css with the same name as their page name.
And freeway does not create a corresponding css file for each page
something is happening in the software that causes Freeway to change the links for each page but not generate the corresponding css files!
I tried to delete all css but Freeway keeps the same behavior.
When I deactivate the HTTPS CDN action everything returns to order.
So there is a conjunction of factors that creates this dysfunction for pages based on the same master page and with an unmodified layout,
Freeway usually creates a single common css sheet for these pages.
In another site based on a master page but where I modified each layout afterwards, Freeway generates as many css sheets as there are pages, this is its normal behavior and in this case I have no no problem when I use this action.
It is a very mysterious bug for me and i try to explain to you in which case it appears.
