[Pro] Forum issue....

Freeway
21

The issue is that you’re going to have to put the JavaScript on the page that will receive the insert, not the page where the insert is created.

I forgot about your search field injection issue here. Try the instructions on a new HTML5 page, otherwise blank. Make sure it looks and works the way you need it to. Then we can thread it back into your composite page.

Walter

On Dec 9, 2013, at 5:13 PM, Roy Gardiner wrote:

The suggested formatting is a bit more consistent between Safari and Firefox from a Search Field size and relative positioning of the button perspectives. However, in Firefox the Search Field box is a rectangle with square corners and in Safari and Chrome the box has rounded corners.

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

22

On 9 Dec 2013, 9:27 pm, waltd wrote:

The issue is that you’re going to have to put the JavaScript on the page that will receive the insert, not the page where the insert is created.

I forgot about your search field injection issue here. Try the instructions on a new HTML5 page, otherwise blank. Make sure it looks and works the way you need it to. Then we can thread it back into your composite page.

Walter

On Dec 9, 2013, at 5:13 PM, Roy Gardiner wrote:

Hi Walter,

With only the Protaculous 2 Action applied?

Thanks.

Best regards,

Roy

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

23

Follow the steps I outlined on a new blank page. Let’s make sure that this looks how you want it to in the first place. If you follow those steps, you will only be using Protaculous 2.

Walter

On Dec 9, 2013, at 5:39 PM, Roy Gardiner wrote:

On 9 Dec 2013, 9:27 pm, waltd wrote:

The issue is that you’re going to have to put the JavaScript on the page that will receive the insert, not the page where the insert is created.

I forgot about your search field injection issue here. Try the instructions on a new HTML5 page, otherwise blank. Make sure it looks and works the way you need it to. Then we can thread it back into your composite page.

Walter

On Dec 9, 2013, at 5:13 PM, Roy Gardiner wrote:

Hi Walter,

With only the Protaculous 2 Action applied?

Thanks.

Best regards,

Roy

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

24

On 9 Dec 2013, 9:43 pm, waltd wrote:

Follow the steps I outlined on a new blank page. Let’s make sure that this looks how you want it to in the first place. If you follow those steps, you will only be using Protaculous 2.

Walter

On Dec 9, 2013, at 5:39 PM, Roy Gardiner wrote:

On 9 Dec 2013, 9:27 pm, waltd wrote:

The issue is that you’re going to have to put the JavaScript on the page that will receive the insert, not the page where the insert is created.

I forgot about your search field injection issue here. Try the instructions on a new HTML5 page, otherwise blank. Make sure it looks and works the way you need it to. Then we can thread it back into your composite page.

Walter

Hi Walter,

With Protaculous 2 applied as per your steps, if I use the Search “Style” for the input/field box, the box won’t scale in height when previewed or viewed in Safari or Firefox, regardless of what is input into the Inspector. When viewed in Firefox the box is taller than when viewed in Safari. So the button doesn’t line up cleanly (height-wise) in one or the other viewer. The input/field box has round corners in both instances, so I would need to use a round button and the discrepancies are more obvious.

If I use the Text “Style” for the input/field box, the boxes will scale in height when previewed or viewed in Safari or Firefox and are very close in size. So the button lines up much better in this instance and the input/field box has square corners. So I like this look better, but this is not following the steps you outlined???

Thanks.

Best regards,

Roy

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

25

What do you see on this page?

http://scripty.walterdavisstudio.com/safari-search

I see the same thing in Firefox and Safari.

Walter

On Dec 9, 2013, at 7:31 PM, Roy Gardiner wrote:

With Protaculous 2 applied as per your steps, if I use the Search “Style” for the input/field box, the box won’t scale in height when previewed or viewed in Safari or Firefox, regardless of what is input into the Inspector.

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

26

On 10 Dec 2013, 1:25 am, waltd wrote:

What do you see on this page?

Untitled

I see the same thing in Firefox and Safari.

Walter

On Dec 9, 2013, at 7:31 PM, Roy Gardiner wrote:

With Protaculous 2 applied as per your steps, if I use the Search “Style” for the input/field box, the box won’t scale in height when previewed or viewed in Safari or Firefox, regardless of what is input into the Inspector.

Hi Walter,

When I view the page with Safari the input/field box is higher than when viewed in Firefox.

Strangely, when I create a page with the input/field box I get the opposite, the box is higher in Firefox than in Safari. I’ve added a button to highlight the height difference: http://test.advancedbarefoot.com/searchform3.html

I have the box height and width set as fixed in the Inspector and as I indicated, regardless of what I input for height, it doesn’t translate into either Safari or Firefox.

Thanks,

Best regards,

Roy

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

27

On 10 Dec 2013, 1:25 am, waltd wrote:

What do you see on this page?

Untitled

I see the same thing in Firefox and Safari.

Walter

Hi Walter,

I’ve pretty much given up on trying to format the Search Elements the way that I want them to look. I’ve spent way too much time on this and need to move on to other areas on the site.

So here’s what I’m going to go with for now: http://test.advancedbarefoot.com/searchtest.php

The only problem that I have now is that the Search feature only works with Firefox and not with Safari, Chrome, or IE.

Try typing insoles or heel pain into the input/field.

Thanks again for all of your assistance.

Best regards,

Roy

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

28

Your search box has lost the attribute that tells it where to get the information from

<form action="sitesearch.php" method="get">

This is missing from the searchtest.php page

D

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

29

Clear your cache. This worked for me.

Walter

On Dec 10, 2013, at 6:29 PM, Roy Gardiner wrote:

The only problem that I have now is that the Search feature only works with Firefox and not with Safari, Chrome, or IE.

Try typing insoles or heel pain into the input/field.

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

30

On 11 Dec 2013, 12:47 am, waltd wrote:

Clear your cache. This worked for me.

Walter

Hi Walter, Dave,

I had to add “sitesearch.php” to the Action field of the Multiple Form Action, then clear my cache. Walter, you must of tried it just after I uploaded the changes.

Thanks again to both of you for your assistance. I’ll come back to the formatting issue at a later date, as I would really like to change the colour of the button.

Best regards,

Roy

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

31

I have a completely different solution for you.

http://actionsforge.com/actions/view/311-simple-site-search-helper

You need to un-do all the steps from your previous efforts – you no longer need to “inject” the form into the page with JavaScript. Simply place the search form as you would normally do with Simple Site Search, apply the Simple Site Search Helper to the same page, and apply the Simple Site Search Button (bundled in the same Action with SSSH) to the submit button.

Under the covers, what it does is the following:

  1. Locates and memorizes the original form setup details before the SSS Action rewrites them.
  2. Locates each of the SSS elements (search field and optional button) and removes their name property, and memorizes their id property for further fiddling later.
  3. Adds an unobtrusive listener function (JavaScript) to the search field (and optionally, to the submit button) that intercepts an attempt to submit the search form (return key or click on the button) and routes it to the search results page.

By removing the name attribute from the search fields, they will no longer be included in the results from a normal form submission on the page, and by adding the observer function to the form elements, they can no longer submit the page form at all. Rather than nesting one form in another (which won’t work, so don’t try) and rather than injecting a second form into the page using the Multiple Forms suite, this just allows both sets of form elements to co-exist without bothering one another.

Walter

On Nov 30, 2013, at 11:15 AM, Roy Gardiner wrote:

Hi Dave,

The TestWrangler did the trick, as did the SearchBox name change, thanks.

I can’t figure out is why I’m losing the Search box and button formatting. The box should have hard not rounded corners and the button should be square and green. When I preview the search_form.html page the formatting is lost as well.

Here’s a link to how it looks: http://test.advancedbarefoot.com/searchtest.html

Here’s a link to a page with how I would like it to look (if possible): http://test.advancedbarefoot.com Any ideas here??

Also, I think that I followed all of the directions to “wire up” Simple Site Search (all three Actions) but for some reason it’s not working. I’ve tried from scratch four times with the same results.

Here’s the links to the other pages:
http://test.advancedbarefoot.com/sitesearch.html
http://test.advancedbarefoot.com/search_form.html

Thanks again for your assistance.

Best regards,

Roy

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

32

On 23 Dec 2013, 1:41 pm, waltd wrote:

I have a completely different solution for you.

Simple Site Search Helper - ActionsForge

You need to un-do all the steps from your previous efforts – you no longer need to “inject” the form into the page with JavaScript. Simply place the search form as you would normally do with Simple Site Search, apply the Simple Site Search Helper to the same page, and apply the Simple Site Search Button (bundled in the same Action with SSSH) to the submit button.

Under the covers, what it does is the following:

  1. Locates and memorizes the original form setup details before the SSS Action rewrites them.
  2. Locates each of the SSS elements (search field and optional button) and removes their name property, and memorizes their id property for further fiddling later.
  3. Adds an unobtrusive listener function (JavaScript) to the search field (and optionally, to the submit button) that intercepts an attempt to submit the search form (return key or click on the button) and routes it to the search results page.

By removing the name attribute from the search fields, they will no longer be included in the results from a normal form submission on the page, and by adding the observer function to the form elements, they can no longer submit the page form at all. Rather than nesting one form in another (which won’t work, so don’t try) and rather than injecting a second form into the page using the Multiple Forms suite, this just allows both sets of form elements to co-exist without bothering one another.

Walter

Hi Walter,

Sorry to take so long to respond, but we got hit by a Ice storm and lost our power on Dec. 21 and it was out for 4 days, then off an on. I’m finally able to get back to the computer.

Thanks so much for the Action, it works with the Site Search (in the Menu Header) and the PHP Easy Form e-mail sign up (in the footer). I’ve removed the Page>No Form action and Multiple Form action for the two items.

Since I’m be using the e-mail form and site search on the various Master pages, I’m wondering if there will be any conflicts when adding additional forms (PHP Easy Forms or others) to additional pages?

Can I simply use the Page>No Form action and Multiple Form action on the e-mail form and additional forms, or is there something else that I’ll need to do?

Thanks again for your assistance.

Happy New Year!

Best regards,

Roy

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

33

This Action only works in the presence of the default (no other Actions used) Freeway form. It doesn’t have any internal logic that would allow it to work with multiple forms (created by the Multiple Form suite) on the same page.

So while you can use it to add a search form to a page that has one default form on it, you cannot use it to add a search form to a page that already has two forms on it.

If you want to make a page that has three forms, you would need to use the Multiple Forms suite to set up two of those, and then I would just hand-code the search form. There’s really no other way I can imagine that this would work out well. The way to figure out what that form should look like is to create a new page in your site that has absolutely nothing else on it except an instance of the Simple Search form. Publish, and view the generated HTML source code in a text editor. Locate the form tag and copy it into a new text document. (Skip the PageDiv and any other HTML structures.) Then locate your search field, and copy that into the search form, so the result looks something like this:

<form action="your_search_results_page.html" method="get">
	<input name="q" type="search" placeholder="Search..." />
	<input name="t" value="1234546778"/>
</form>

Copy that into a Markup Item on your two-formed page, and make sure that the Markup Item stays outside of any of the other forms you’ve already created with the Multiple Form suite. Because this form element is self-contained within one Markup Item, it should stay out of your way.

Walter

On Dec 31, 2013, at 10:24 AM, Roy Gardiner wrote:

On 23 Dec 2013, 1:41 pm, waltd wrote:

I have a completely different solution for you.

Simple Site Search Helper - ActionsForge

You need to un-do all the steps from your previous efforts – you no longer need to “inject” the form into the page with JavaScript. Simply place the search form as you would normally do with Simple Site Search, apply the Simple Site Search Helper to the same page, and apply the Simple Site Search Button (bundled in the same Action with SSSH) to the submit button.

Under the covers, what it does is the following:

  1. Locates and memorizes the original form setup details before the SSS Action rewrites them.
  2. Locates each of the SSS elements (search field and optional button) and removes their name property, and memorizes their id property for further fiddling later.
  3. Adds an unobtrusive listener function (JavaScript) to the search field (and optionally, to the submit button) that intercepts an attempt to submit the search form (return key or click on the button) and routes it to the search results page.

By removing the name attribute from the search fields, they will no longer be included in the results from a normal form submission on the page, and by adding the observer function to the form elements, they can no longer submit the page form at all. Rather than nesting one form in another (which won’t work, so don’t try) and rather than injecting a second form into the page using the Multiple Forms suite, this just allows both sets of form elements to co-exist without bothering one another.

Walter

Hi Walter,

Sorry to take so long to respond, but we got hit by a Ice storm and lost our power on Dec. 21 and it was out for 4 days, then off an on. I’m finally able to get back to the computer.

Thanks so much for the Action, it works with the Site Search (in the Menu Header) and the PHP Easy Form e-mail sign up (in the footer). I’ve removed the Page>No Form action and Multiple Form action for the two items.

Since I’m be using the e-mail form and site search on the various Master pages, I’m wondering if there will be any conflicts when adding additional forms (PHP Easy Forms or others) to additional pages?

Can I simply use the Page>No Form action and Multiple Form action on the e-mail form and additional forms, or is there something else that I’ll need to do?

Thanks again for your assistance.

Happy New Year!

Best regards,

Roy

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

34

On 31 Dec 2013, 3:18 pm, waltd wrote:

This Action only works in the presence of the default (no other Actions used) Freeway form. It doesn’t have any internal logic that would allow it to work with multiple forms (created by the Multiple Form suite) on the same page.

So while you can use it to add a search form to a page that has one default form on it, you cannot use it to add a search form to a page that already has two forms on it.

If you want to make a page that has three forms, you would need to use the Multiple Forms suite to set up two of those, and then I would just hand-code the search form. There’s really no other way I can imagine that this would work out well. The way to figure out what that form should look like is to create a new page in your site that has absolutely nothing else on it except an instance of the Simple Search form. Publish, and view the generated HTML source code in a text editor. Locate the form tag and copy it into a new text document. (Skip the PageDiv and any other HTML structures.) Then locate your search field, and copy that into the search form, so the result looks something like this:

Copy that into a Markup Item on your two-formed page, and make sure that the Markup Item stays outside of any of the other forms you’ve already created with the Multiple Form suite. Because this form element is self-contained within one Markup Item, it should stay out of your way.

Walter

Hi Walter,

I followed your suggestions as best I understood, but the different forms aren’t playing nicely. The Site Search doesn’t show and the e-mail form doesn’t work. The mock up form in the center of the page works though.

Here’s a page with two forms and the Site Search html code within a Markup Item:
http://test.advancedbarefoot.com/searchtest2.php

Here’s the Search Form on a blank page: http://test.advancedbarefoot.com/form1.html

Here’s the page that incorporated your new Helper action with everything working nicely: http://test.advancedbarefoot.com/searchtest.php

Any thoughts?

Thanks.

Best regards,

Roy

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

35

Okay, this looks to have been created by taking the Search field code from a page that had both the Simple Site Search field added AND the SSS Submit Action on the button. That’s not what I intended.

Also your code is invalid. I had to copy and paste it out into a text editor so I could see what was going on, but here’s your code cleaned up so it’s readable (but not changed in any way). See if you can spot the basic problem here:

<div id="SiteSearch" class="f-ms">
  <p class="f-fp f-lp">
    <form action="sitesearch.php" method="get">
      <div id="PageDiv">
        <div id="SiteSearch" class="f-ms">
          <p class="f-fp f-lp">
            <input id="Button1" class="f-ms" type=submit value="&gt;" name="s">
            <input id="Searchfield1" class="f-ms" type=text placeholder="Search" size=35 name="q">
            <input name="t" type="hidden" value="1388507934270">&nbsp;
          </p>
        </div>
      </div>
    </form>
  </p>
</div>

I’ll give you a hint. No two things on the same page may have the same ID. You have two duplicates here (one is inferred, since I didn’t include the outermost #PageDiv in this code snippet).

Working from this, here’s the only thing you should be pasting into your Markup Item, and your Markup Item must be a positioned element, so it doesn’t create a P tag around the form. (If you must make this MI an inline object, then use the CrowBar Action instead of the Markup Item, so it will properly remove the surrounding P tag.)

<form action="sitesearch.php" method="get">
  <input id="Button1" class="f-ms" type=submit value="&gt;" name="s">
  <input id="Searchfield1" class="f-ms" type=text placeholder="Search" size=35 name="q">
  <input name="t" type="hidden" value="1388507934270">
</form>

With just this code pasted into your page in the proper place, you should have a third (working) form for searching the page. I didn’t see any form nesting or overlap in the page code, it looked as though it should work properly. I suspect that your issues are cosmetic, and cleaning up the HTML will allow the CSS to work as you expect.

Walter

On Dec 31, 2013, at 1:07 PM, Roy Gardiner wrote:

Here’s a page with two forms and the Site Search html code within a Markup Item:
http://test.advancedbarefoot.com/searchtest2.php

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

36

On 31 Dec 2013, 5:57 pm, waltd wrote:

With just this code pasted into your page in the proper place, you should have a third (working) form for searching the page. I didn’t see any form nesting or overlap in the page code, it looked as though it should work properly. I suspect that your issues are cosmetic, and cleaning up the HTML will allow the CSS to work as you expect.

Walter

Hi Walter,

Thanks! Your cleaned up code did the trick.

I’m really green at this and may have bitten off more than I should have when I tried to build this site myself. I’m learning though… slowly and a little bit at a time.

Thanks again.

Best regards,

Roy

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

37

I’ve run into another Simple Site Search issue.

Our site has a lot of content pages and to better organize them I have placed like pages in separate “Content Related” folders within the Site Folder.

The Landing Page (index page), Site Map and Site Search Results pages are simply located within the Site Folder (not in Content Related Folders). When I use the Site Search feature on any of these pages everything works fine (see: http://test.advancedbarefoot.com/).

However, when I use Site Search on any of the pages that are located in a Content Related Folder, I get an Error 404 - Not Found Message. The URL of the related Error pages looks something like this: http://test.advancedbarefoot.com/The%20Science/sitesearch.php?s=>&q=heel+pain&t=1388507934270. “The Science” is the name of one of the Content Related Folders.

If I delete the Content Related Folder name from the URL, the Search Results page shows properly.

Is there a work around for this or do I have to remove all of the Content Related Folders and only keep the content pages in the Site Folder?

Thanks.

Best regards,

Roy

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

38

I’m not sure it’s going to fix this particular issue, but you should never include spaces or any punctuation besides an underscore, hyphen, or dot in any URL – in any part of any URL. I can’t stress that strongly enough. A legal URL is the first place to start here, because what SSS does under the covers is quite hairy, and it’s entirely reasonable to expect that all of your inputs will be correct before you start trying to guess how it’s going to generate output.

Walter

On Apr 7, 2014, at 10:05 AM, Roy Gardiner wrote:

I’ve run into another Simple Site Search issue.

Our site has a lot of content pages and to better organize them I have placed like pages in separate “Content Related” folders within the Site Folder.

The Landing Page (index page), Site Map and Site Search Results pages are simply located within the Site Folder (not in Content Related Folders). When I use the Site Search feature on any of these pages everything works fine (see: http://test.advancedbarefoot.com/).

However, when I use Site Search on any of the pages that are located in a Content Related Folder, I get an Error 404 - Not Found Message. The URL of the related Error pages looks something like this: http://test.advancedbarefoot.com/The%20Science/sitesearch.php?s=>&q=heel+pain&t=1388507934270. “The Science” is the name of one of the Content Related Folders.

If I delete the Content Related Folder name from the URL, the Search Results page shows properly.

Is there a work around for this or do I have to remove all of the Content Related Folders and only keep the content pages in the Site Folder?

Thanks.

Best regards,

Roy

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

39

Hi Walter,

If you are referring to the % between The and Science, Freeway is generating that.

If that is what you are referring to, I’m not sure that is what is causing the issue. Many of the Content Related Folder names are only one word. For example, on the landing page http://test.advancedbarefoot.com/ see the Header drop down menu’s Products, Testimonials, Store pages. Each of these menu headings corresponds to a identically named Content Related Folder.

It appears when a search is initiated, that either Freeway or Simple Site Search is adding the pages’ Content Related Folder name before “sitesearch.php…” and therefore, the page can’t be located because it is not in that folder. I don’t know how or why that is happening and how to stop it.

Thanks.

Best regards,

Roy

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

40

But isn’t the folder actually named ‘The Science’? You need to make that the-science or the_science – no space. That’s what I’m referring to. Freeway should only be providing links to content at its URL – whatever that URL is. The %20 is the browser-generated escape for a space, Freeway isn’t adding that in any way. But your URLs should be entirely without spaces, then you won’t have to worry about this particular issue.

Walter

On Apr 7, 2014, at 10:48 AM, Roy Gardiner wrote:

Hi Walter,

If you are referring to the % between The and Science, Freeway is generating that.

If that is what you are referring to, I’m not sure that is what is causing the issue. Many of the Content Related Folder names are only one word. For example, on the landing page http://test.advancedbarefoot.com/ see the Header drop down menu’s Products, Testimonials, Store pages. Each of these menu headings corresponds to a identically named Content Related Folder.

It appears when a search is initiated, that either Freeway or Simple Site Search is adding the pages’ Content Related Folder name before “sitesearch.php…” and therefore, the page can’t be located because it is not in that folder. I don’t know how or why that is happening and how to stop it.

Thanks.

Best regards,

Roy

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