I’m checking my clients site and noticed it failed the W3C validation check with one error:
Line 311, Column 31: ID “SEARCHBOX” already defined
<input name=“t” type=“hidden” value="1…
An “id” is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element).
Line 310, Column 11: ID “SEARCHBOX” first defined here
<div id=“searchbox” style="position:absolute; left:816px; top:308px; width:158…
I’ve read though the error and I’m afraid I don’t understand it. I’ve checked the same of the item its referring to in the inspector - it’s a form field on the master page (and on every page) called ‘searchbox’. I’ve changed the name of it and tried again (to something like searchbox0) and the error is still there. Is this saying it needs to have a different name on every page?
When you click on an object in Freeway Pro, you can see it’s ID value in
the Inspector - in a field marked Title.
Your search field on the upper-right of your page is in an html item named
“searchbox”. It contains a text input item also named “searchbox”. Change
the name of the html item.
–
Ernie Simpson
On Wed, Aug 22, 2012 at 4:54 AM, Neil email@hidden wrote:
Hi,
I’m checking my clients site and noticed it failed the W3C validation
check with one error:
Line 311, Column 31: ID “SEARCHBOX” already defined
<input name=“t”
type=“hidden” value="1…
An “id” is a unique identifier. Each time this attribute is used in a
document it must have a different value. If you are using this attribute as
a hook for style sheets it may be more appropriate to use classes (which
group elements) than id (which are used to identify exactly one element).
Line 310, Column 11: ID “SEARCHBOX” first defined here
<div id=“searchbox” style="position:absolute; left:816px;
top:308px; width:158…
I’ve read though the error and I’m afraid I don’t understand it. I’ve
checked the same of the item its referring to in the inspector - it’s a
form field on the master page (and on every page) called ‘searchbox’. I’ve
changed the name of it and tried again (to something like searchbox0) and
the error is still there. Is this saying it needs to have a different name
on every page?
Many thanks for the reply. I though it was that, so I change the name of the item, re-uploaded the site and I get the same erro (but with the new name for the item.
First of all, you don’t need to upload the site to see if the id name has
changed in the code. Opening the page as text in the text editor or
selecting View Source from any web browser should verify your success in
changing the id.
Second, if you change the name of the html item, does the code reflect that
change? If not, did you use the Extended styling to add an id to that html
item, thus over-riding FWP?
Third, if you change the name of the html item, is the code for the text
input field changing to match?
Freeway Pro will not knowingly allow duplicate IDs, so I cannot imagine how
you are unknowingly circumventing this safeguard.
The code from your page…
And again, for emphasis…
div id=“searchbox”
input id=“searchbox”
–
Ernie Simpson
On Wed, Aug 22, 2012 at 8:28 AM, Neil email@hidden wrote:
I believe the issue is linked to the use of the Simple Site Search Action which had an issue where the search field could (incorrectly) take on the ID of the enclosing div. I’m sure Joe can confirm this but I seem to recall this issue was resolved in a later version of the Action. Upgrade the application to the latest version and you should see the issue resolve itself.
Regards,
Tim.
Thanks for your reply. I’ve checked the action I’m using and its V 1.5. Is this a core Freeway action, as I can’t find another version on Actionsforge etc. to download and update?
That’s a terrific answer Tim, and explains things all around. However, he
is using the current version of FWP – by my reckoning anyway. From the page
in question…
If the SSS action is applying the div ID to the input field, we could
confirm it by changing the Title (ID) of the html item (div) and see if the
id of the input field changes in the source code… yes?
–
Ernie Simpson
On Wed, Aug 22, 2012 at 9:13 AM, Tim Plumb email@hidden wrote:
I believe the issue is linked to the use of the Simple Site Search Action
which had an issue where the search field could (incorrectly) take on the
ID of the enclosing div. I’m sure Joe can confirm this but I seem to recall
this issue was resolved in a later version of the Action. Upgrade the
application to the latest version and you should see the issue resolve
itself.
Regards,
Tim.
Would it help if I changed the name of it in the inspector as Ernie mentions, re-upload ad you take a look? I tried this earlier and it still reports an erro (but obviously using the new name I tried).
Most likely this is related to FreezeForm. I will have a look at the Action and if that’s the case, release a new version. You might be able to work around this by not drawing the search form directly on the page. Rather, draw an HTML box where you want the field to appear, then double-click inside that box and insert an inline search field. If the field is drawn by an Action, look in Insert / Action Items / Your Search Action Here. If the Action gets applied to a normal text field, then use Insert / [Form Items] Text Field. Click once on the inline text field and apply your actions to that.
Walter
On Aug 22, 2012, at 9:45 AM, Neil wrote:
Would it help if I changed the name of it in the inspector as Ernie mentions, re-upload ad you take a look? I tried this earlier and it still reports an erro (but obviously using the new name I tried).
you indeed had changed the Title (ID) of the html item (div), and
indeed, the ID of the input field changed to match.
So Tim gets credit for calling out the Simple Site Search action, and since
you are using the current version of FWP, Joe gets to work on a solution.
Yay!
I would suggest trying this as a workaround:
Leave the named alone for now… the action seems to be causing the mess, so
let’s see if we can fool it. First, select the html item (the div box).
Then go to menu Item > Extended… to open the Extended attributes for div
window. Make sure the div tab is selected then click the New… button. Enter
id into the Name field and searchmysite into the value. Click OK,
republish, reupload, and check.
–
Ernie Simpson
On Wed, Aug 22, 2012 at 9:45 AM, Neil email@hidden wrote:
Would it help if I changed the name of it in the inspector as Ernie
mentions, re-upload ad you take a look? I tried this earlier and it still
reports an erro (but obviously using the new name I tried).
I just spotted a possible culprit in FreezeFormItem. If the form element doesn’t have an ID (and Freeway never sets one, so this is usually true) then the Action will set the ID to match the fwItem. In the case of a drawn form element (layer item on the page) that will always be the enclosing DIV.
You can test this by removing FreezeForm from the input, and seeing if the problem resolves. I will figure out another way to do this.
Walter
On Aug 22, 2012, at 10:26 AM, Joe Billings wrote:
Hi Walter,
I was just replying with a link to an updated version of the Action. Here it is:
Version 0.2 of the Action was adding the id of the Freeway item to the input and then adding the appropriate CSS rule to the stylesheet.
In 0.3 I changed this so that the id was added to the input’s enclosing item only if it does’t already exist (table based items and inflow items). I then updated the selector in the rule to target “id input/textarea/select”. It should work in all cases.
Joe
On 22 Aug 2012, at 15:31, Walter Lee Davis email@hidden wrote:
I just spotted a possible culprit in FreezeFormItem. If the form element doesn’t have an ID (and Freeway never sets one, so this is usually true) then the Action will set the ID to match the fwItem. In the case of a drawn form element (layer item on the page) that will always be the enclosing DIV.
You can test this by removing FreezeForm from the input, and seeing if the problem resolves. I will figure out another way to do this.
Walter
On Aug 22, 2012, at 10:26 AM, Joe Billings wrote:
Hi Walter,
I was just replying with a link to an updated version of the Action. Here it is:
If you are using the old FreezeForm Action (never released on ActionsForge, then you will need to remove it from the elements in your page, then remove it from Freeway entirely. Replace it with this one: FreezeFormItem - ActionsForge and you should be all set. The ID of the form element will be set to match the element’s name attribute, not the ID of the item the Action is applied to (which might not be the form element, in the case of a layered form element). This will ensure that you can set the ID of the form element and the ID of the DIV that holds it on the page to two different things.
Walter
On Aug 22, 2012, at 10:31 AM, Walter Lee Davis wrote:
I just spotted a possible culprit in FreezeFormItem. If the form element doesn’t have an ID (and Freeway never sets one, so this is usually true) then the Action will set the ID to match the fwItem. In the case of a drawn form element (layer item on the page) that will always be the enclosing DIV.
You can test this by removing FreezeForm from the input, and seeing if the problem resolves. I will figure out another way to do this.
Walter
On Aug 22, 2012, at 10:26 AM, Joe Billings wrote:
Hi Walter,
I was just replying with a link to an updated version of the Action. Here it is:
Thank you for all your replies, it’s really appreciated.
Right then, I just tried removing the freeze form action completely, re-uploaded and run it through validation again - and… error is gone. So, I asume that’s the culprit.
I tried to use the new action off Jo (0.3) but when I install it (get the standard 'do you want to replace older action etc, select yes) the action still appears as V0.2?
If you are using Lion, click anywhere on the desktop and then press Shift - Command - G (go to folder). In the dialog that appears, type Library/Application Support/Freeway 5/Actions/General. You should see a Finder window with all of your Actions in it. Locate anything with the word Freeze in it. If you see more than one (sort alphabetically), then make sure that you keep FreezeFormItem and get rid of FreezeFormAction. The correct version is 1.1.
As Dave noted, you may need to check through all open documents for any other instances of the old Action, remove them from the pages, and then publish once to clear the cache.
Walter
On Aug 22, 2012, at 10:46 AM, Neil wrote:
Hi Guys,
Thank you for all your replies, it’s really appreciated.
Right then, I just tried removing the freeze form action completely, re-uploaded and run it through validation again - and… error is gone. So, I asume that’s the culprit.
I tried to use the new action off Jo (0.3) but when I install it (get the standard 'do you want to replace older action etc, select yes) the action still appears as V0.2?
If you’re using an earlier version of Mac OS X, then you don’t need this step, because the ~/Library folder isn’t hidden from view.
Walter
On Aug 22, 2012, at 10:51 AM, Walter Lee Davis wrote:
If you are using Lion, click anywhere on the desktop and then press Shift - Command - G (go to folder). In the dialog that appears, type Library/Application Support/Freeway 5/Actions/General.
