Technical Support FAQ

Expand/Collapse  1. Flyout menus don't display when I preview the page on my local computer.

There are several possible reasons your flyout menus do not display when you preview the page.
1.1 You are using an old version of the extension.
Download the latest version of the extension from your account in Client Center. Trial users can download from Download Center.
1.2 There is a possible conflict on your page.
If you received an error on the page when you tried to display the menus, there may be a conflicting third-party script on your page. Look for possible conflicts between scripts, such as onload event handlers. The Pluginlab menu script is set to load and be active when the HTML page is opened. This is accomplished using the onload attribute in the <body> tag. The tag looks like this:
<body onload="PL..._onload()">
If there are other onload commands in the body tag, the other commands may have prevented the Pluginlab command from running.
Remove conflicting event handlers.
Support:
You can contact us directly and we will look at your scripts to help resolve these issue. Login to Client Center.
1.3 The menu wasn't saved on your page.
The menu was not installed correctly. While installing the menu extension your Dreamweaver was open. Please make sure it's always closed when installing new extensions or product updates.
The same problem can occur (the menu wouldn't save) if you did not restart Dreamweaver before creating and previewing the menu after product installation
Don't open the Extension Manager from the Start Menu or by double-click it in a folder when Dreamweaver is open, it may also cause this problem.
Always follow these steps when reinstalling an update:
  • Save your HTML page
  • Close Dreamweaver
  • Start the Extension Manager
  • Reinstall the extension
  • Reopen Dreamweaver
  • Open the HTML page and preview the page again
Note:
Always use the menu extension the location of the script file or change its name.
Learn More:
Read the tutorial Learning About the JavaScript (.JS) File. To learn about how the location of files is indicated in the script file, read Understanding Path Names.

Expand/Collapse  2. Flyout menus don't display when I preview the page on my Web server.

There are several possible reasons your flyout menus do not display when you preview the page on your server.
2.1 The most likely problem is that the PluginLab script file cannot be found.
2.1.1. The path to the script file is not the same on the Web server as it is on your local computer.
You need to make sure these paths are identical.
  • For example, on your local computer, you defined your site in Dreamweaver to have a site root called MyRoot under the My Documents folder.
  • The drive path on your computer looks like this:
    C:\My Documents\MyRoot
  • The PluginLab folder is located below the MyRoot folder:
    C:\My Document\MyRoot\PluginLab\
  • You created all of your pages and added the menus in this structure.
To test your menus on your Web server you need to do the following:
  • Create a folder on the Web server called TestSite.
  • Load all of the new pages with menus and the PluginLab folders into this folder.
The structures on the two computers look like this:
Structure on the local computer
Structure on the Web server
The flyout menus won't display because you changed the relationship of the site root - MyRoot - to the folder containing the script file, PLHFO.js by adding the folder TestSite on your Web server. PLHFO.js is now two folders below MyRoot, rather than one level below MyRoot.
Support:
You can contact us directly and we will look at your scripts to help resolve these issue. Login to Client Center.
2.1.2. The name of the folder on your local machine differs from the name of the folder on your web server.
Please make sure you have named the folder with the script files on you web server the same way you have it locally.
2.2 You may not have uploaded the .JS file (PLHFO.js) that contains the instructions for how the browser is to handle the flyout menu to the Web server.
The PLHFO.js file must be in /PluginLab/Scripts folder on the Web server and the PluginLab folder must be in the same location relative to the site root as it was on the local computer.
Please do one of the following:
Move the PLHFO.js file to the /PluginLab/Scripts folder on the Web server.
Or move the PluginLab folder to the same location relative to the site root as it is on the local computer.
Note:
You can guarantee your files and folders are put into the right folders on the Web server if you use Dreamweaver's upload functions. When you define your project site in Dreamweaver, define a remote site (the path to your Web server root) and define the FTP or HTTP access information needed for Dreamweaver to upload and download files automatically. As you add or edit pages or update menus across multiple pages, use Dreamweaver to synchronize the remote site with the local site and update the pages on the Web server automatically. You can cloak any local files you do not want uploaded to the Web server.
Learn More:
Read Defining a Site in Dreamweaver or open Dreamweaver Help (F1 or Using Dreamweaver on the Help menu) and read the topics in Managing Your Sites.
You can learn more about the .JS file by reading the tutorial Learning About the Java Script (.JS) File.
To learn more about how the locations of files are defined in the script file, read Understanding Path Names.
You can learn more about defining a site in Dreamweaver by reading the tutorial Defining a Site in Dreamweaver.

Expand/Collapse  3. Images in menus don't show when I preview the page on my local computer.

There are several possible reasons why your mages do not display when a Web page is opened from your local computer:
3.1 The menu images are not located in the relative path indicated in the script file.
This can happen if you:
Edited the path name directly in Code View in Dreamweaver
Moved the image and not updated the menus
Created menus before the HTML page was saved for the first time
Please make sure you have placed the images in the folder defined in the script file.
3.2 The menu images are not located in the absolute path indicated in the script file.
An absolute path name includes the drive location of the file and all of the folders from the drive name to the image file.
If the image is no longer located along this path, it does not display.
This can happen if you insert menus and images into an HTML in Dreamweaver before you have saved the HTML file into the project site.
Open the extension and point to the image again. The extension will rewrite the path name as an absolute path name.
Note:
Always use the menu extension to designate the names and locations of images to be used in menus.
Learn More:
To learn more relative path names and about how the locations of files are defined in the script file, read Understanding Path Names.
3.3 The image is not in the Images folder under the PluginLab folder below your project site folder.
Move the images to the PluginLab/Images folder or reselect the images using the extension.
3.4 The folder containing the images is not part of the defined site.
The image does not display if you referenced the image by typing its location as an attribute for the <img> tag rather than using the extension to point to the image and that location is not within the defined site.
Please always follow these steps:
  • Move the images to a location within your defined site.
  • Open the extension.
  • Point to the new image location.
  • Update all of the pages using menus so that the new location is specified in each menu instance.
3.5 The image names were changed after the menus were created.
Open the extensions and point to the images with their new names.

Expand/Collapse  4. Images in menus don't show when I open the page from my Web server.

There are several possible reasons why your mages do not display when you open the page from your Web server:
4.1 The images cannot be found.
Check the link to the image to find and correct the problem. It may be:
the images were uploaded to a different folder
the folder was renamed
the folder is not in the same location relative to the site root or the HTML pages
4.2 The images are not located in the absolute path indicated in the script file.
An absolute path name includes the drive location of the file and all of the folders from the drive name to the image file.
If the image is no longer located along this path, it does not display.
Open the extension and point to the image again. The extension will rewrite the path name as an absolute path name.
This can happen if you insert menus and images into an HTML in Dreamweaver before you have saved the HTML file into the project site. If you upload the pages to the Web server without changing the path names, the images do not display when you open the page from the Web server.
Always follow these steps:
  • On your local computer open the extension
  • Correct the locations for all of the images in your menus
  • Then update all of the pages using menus
  • Upload the new pages to the Web server
Note:
Always use the menu extension to designate the names and locations of images to be used in menus.
Learn More:
Read more about path names in Understanding Path Names.
4.3 The images are not in the location indicated by the path name.
The image must be in the location indicated in the src= attribute in the <ing> tag the extension writes into the scripts on each HTML page using menus.
If the PluginLab folder or the pages are not in the same folders and the same locations as they were on your local machine, the images may not display.
Correct the folder and file structure on the Web server to match the structure on your local computer.
4.4 You changed the image names after you created the menus.
Upload images with the correct names or open the extension and rename the images.
Update all of the pages,
And then upload all of the files to the Web server again.

Expand/Collapse  5. What is the PLHFO.JS?

PLHFO.JS is the JavaScript file used to give instructions to the browser about how to open, close, and display your main menu and flyout menus.
This script file is created by the PluginLab menu extension when you open the extension dialog box and select options on the various tabs.
This file is saved in the PluginLab/Scripts folder on default.
Learn More:
Read the tutorial Learning About the JavaScript (.JS) File.

Expand/Collapse  6. Can I change the name of the file PLHFO.JS?

Yes, you can.
Always change the name in the menu extension dialog box only.
Do not change it by opening it in Notepad or Dreamweaver or some other program and save it with a different name.
Do not change it manually in the HTML code of a page.
Learn More:
Read the tutorial Learning About the JavaScript (.JS) File.

Expand/Collapse  7. Can I change the folder named "PluginLab" to one I choose?

Yes, you can.
Always change the folder name in the menu extension dialog box only.
Do not change it by opening it in Notepad or Dreamweaver or some other program and saving it with a different name.
Do not change it manually in the HTML code of a page.
It is a good idea to create the new folder and move copies of the images and JavaScript to the new folders before you open the menu extension dialog box. Now, open the extension dialog box in Dreamweaver and browse to the new location for whatever you have moved or renamed.
Learn More:
Read the tutorial Learning About the JavaScript (.JS) File.

Expand/Collapse  8. Can I edit the HTML page or JavaScript by hand?

No, you cannot.
Doing so is a violation of your license agreement.
Always use the menu extension dialog box to make changes to your menus.
This guarantees that your changes are made correctly and saved correctly.
Learn More:
Learning About the JavaScript (.JS) File.

Expand/Collapse  9. Can I use document-relative paths for the PluginLab scripts and images?

Yes, you can use document-relative paths.
Note:
If you use document-relative paths all of the pages using menus must be in a location with the same relationship to the PluginLab folders. This method works well if the site's files are seldom or never moved to different locations.
Here are some basic facts you should know about document-relative paths:
They are the most appropriate paths to use for local links in most websites.
They're particularly useful when the current document and the linked document are in the same folder and are likely to remain together.
You can use a document-relative path to link to a document in another folder by specifying the path through the folder hierarchy from the current document to the linked document.
The core concept of document-relative paths is to omit the part of the absolute URL that is the same for both the current document and the linked document, providing only the portion of the path that differs.
Dreamweaver can handle all of the path names in your site automatically if you make all changes to file locations and names in the Dreamweaver Files panel, and if you set up your site definition to do all of the uploading and downloading of site files automatically.
For avoiding mistakes, carefully study the examples below:
  • The pages are all at the site root level and the PluginLab folders are at the site root level:
    MyRoot
    If you select Document as the relative path for images, the extension writes out the document relative path name as PluginLab/Scripts/PLHFO.js
  • You can also put all of the site's pages into a specific folder (as below) where the pages are in the Pages folder at the site root level and install the PluginLab folders within the Pages folder, and then specify image paths as document relative.
    MyRoot
    The extension writes out the document relative path as PluginLab/Scripts/PLHFO.js
  • If the file index.htm is at the site root level, and the other pages of the site and the PluginLab folder are in the Pages folder at the site root level (as below), you must use site root-relative paths, since the home page and the other pages have different relationships to the PluginLab folder.
    MyRoot
    To allow using document-relative paths, move the PluginLab folder to the same level as index.htm (as below). You could also move all pages using menus into the same folder so that all pages using menus have the same relationship to the PluginLab script.
    MyRoot
    If you move the PluginLab folder as shown above and choose document-relative paths, the extension writes the path names to the different pages as shown below:
Learn More:
Read more about path names in Understanding Path Names.

Expand/Collapse  10. What are Site-Root-Relative Paths?

You have three options when you set links in HTML:
  • an absolute path,
  • a document-relative path,
  • or a site-root-relative path.
What kind of link you should use will depend on how your site is organized.
Here are some basic facts you should know about site-root-relative paths:
They path from the site's root folder to a document.
A site root-relative path begins with a leading forward slash, which stands for the site root folder.
For example, suppose, you have a site with the following structure:
To link from vim_adv.html to other files:
- to link from vim_adv.html to scrollbar.html the site-root path is /Pluginlab/My pages/scrollbar.html
- to link from vim_adv.html to sample.html in the Hmenu folder the site-root path is /Pluginlab/My pages/Hmenu/sample.html
- to link from vim_adv.html to info.html in the root the site-root path is just /info.html
- to link from vim_adv.html to heading.gif in the Images folder the site-root path is /Pluginlab/Images/heading.gif
The default path in Pluginlab extensions is relative to the Site Root.
When browsing to select files for linking, use the Relative To option to choose either Site Root, or Document as the type of path and the path will be specified automatically.
Note:
To use root-relative paths, you need a properly defined site with a unique local root folder. Besides, Site-Root-Relative links don't work until you save the document in a local site.
Advantages of site-root relative paths:
A root-relative path provides the best way to specify links in a Web site in which you need to frequently move HTML files from one folder to another.
When you move a document that contains root-relative links, you don't need to change the links; for example, if your HTML files use root-relative links for dependent files (such as images), then if you move an HTML file, its dependent-file links are still valid.
A root-relative path is the best choice when you use "included" files in a site that has multiple directories. Using "included" files can greatly decrease the development time of a site. Instead having to keep recreating it on each page, we can make it its own file and include it into every page on the site.
A root relative path always starts at the root of the site and works down. So no matter where the page is within the site's hierarchy, the link will always start at the root of the site in order to get where it is going.
Use this type of paths if you are working on a large Web site that uses several servers, or one server that hosts several different sites.
Disadvantages of site-root relative paths:
If path to your Site Root changes then all site-root relative links will break.
When you move or rename the documents linked to with root-relative links, you do need to update those links, even if the documents' paths relative to each other haven't changed. For example, if you move a folder, all root-relative links to files within that folder must be updated.
If you open a local page that uses root-relative links in your browser (without using Preview in Browser from within Dreamweaver), the links don't work. This is because browsers don't recognize site roots-servers do. To preview a set of pages that use root-relative links, select Preview Using Local Server (to use this option, you must be running a Web server on your local computer) or put the files on a remote server and view them from there.
Learn More:
Read more about path names in Understanding Path Names.
Read more about defining a site in Dreamweaver in Defining a Site in Dreamweaver.

Expand/Collapse  11. What are Document-Relative Paths?

You have three options when you set links in HTML:
  • an absolute path,
  • a document-relative path,
  • or a site-root-relative path.
What kind of link you should use will depend on how your site is organized.
Here are some basic facts you should know about document-relative paths:
They are the most appropriate paths to use for local links in most websites.
They're particularly useful when the current document and the linked document are in the same folder and are likely to remain together.
You can use a document-relative path to link to a document in another folder by specifying the path through the folder hierarchy from the current document to the linked document.
The core concept of document-relative paths is to omit the part of the absolute URL that is the same for both the current document and the linked document, providing only the portion of the path that differs.
Document-relative paths define the path to find the linked file, starting from the current document.
For example, suppose, you have a site with the following structure:
You create links from vim_adv.html to other files as follows:
- to link from vim_adv.html to scrollbar.html (both files are in the same folder) the relative path is just scrollbar.html
- to link from vim_adv.html to sample.html in the Hmenu folder the relative path is Hmenu/sample.html.
Each forward slash / represents moving down one level in the folder hierarchy.
- to link from vim_adv.html to units.html in the Pluginlab folder the relative path is ../units.html
Each ../ represents moving up one level in the folder hierarchy.
If you need to move up two directories, and to info.html in the root, the path would be like the following: ../../info.html.
- to link from vim_adv.html to heading.gif in the Images folder the relative path is ../Images/heading.gif.
The default path in Pluginlab extensions is relative to the Site Root.
When you change the path type in the Relative To field, Dreamweaver uses your choice as the default path type for any future links until you change the path type again.
Note:
You should always save a new document before creating document-relative links, since the document-relative path is not valid without a definite starting point.
Advantages of document-relative paths:
Once a document-relative link is correctly made and the structure of your site does not change then the whole site can be moved to different locations on the server or to different servers without document-relative links breaking.
When you move a group of files as a group, so that they keep the same relative paths between them-for example, when you move an entire folder, so that all the files inside that folder retain the same relative paths to each other-you do not need to update document-relative links between those files.
Disadvantages of document-relative paths:
When you move an individual file that contains document-relative links, or an individual file that is linked to by a document-relative link, you do need to update those links.
Document-relative links do not allow using "included" files. For example, if the image is found in many different places on your site at different levels then the document-relative link to the image will be different each time you use it. The link will break as the relative path is different.
It is difficult to make global changes to the entire site for document-relative links. So, sometimes they are considered hard to maintain.
Learn More:
Read more about path names in Understanding Path Names.

Expand/Collapse  12. What is the Pluginlab Auto Path Adjustment Feature?

The Pluginlab Auto Path Adjustment Feature is specially developed to prevent the problem of broken links when you test HTML pages locally or on your Web server.
The default path in Pluginlab extensions is relative to the Site Root. The Pluginlab Auto Path Adjustment Feature automatically transforms Site-Root-Relative paths to one of the two other types.
There are three possible strategies you can choose from to use the Pluginlab Auto Path Adjustment Feature helpfully.
12.1 You can leave Site-Root-Relative paths intact.
12.1.1 To test your menu locally:
  • Define your site in Dreamweaver to have a Local Root Folder in the root of a hard disk, such as the root of drive W:\. For example, your Local Root Folder is W:\. The drive path to the script file PLHFO.js is now W:\Pluginlab\Scripts\PLHFO.js.
  • The site-root-relative path to the script file generated by the menu extension is /Pluginlab/Scripts/PLHFO.js
  • When you preview the local page in a browser, the script file is found successfully in W:\Pluginlab\Scripts\PLHFO.js, the flyout menu will display.
  • If you do not define your Local Root Folder in the drive root, menu does not work because the PluginLab script file cannot be found.
  • If you do not wish to use a root of your hard disk as a Local Root Folder, here is another way to make site-root-relative links work properly:
    Use the SUBST command to set the directory your site contents is in and subdirectories thereafter to a virtual drive.
    For example, your site's files are located in C:\Inetpub\wwwroot\MySite. SUBST W: substitutes this fully qualified path to a virtual drive W:\. Now all you have to do is to define your site in Dreamweaver to have a Local Root Folder in the root of the virtual drive W:\.
Note:
If you were to reboot your computer this will clear the SUBST command and put your drives back to original letters (unless command placed into the Startup).
12.1.2 To test your menu on the Web server:
You will need to upload all of the contents of your Local Root Folder directly into the site root on the Web server or into the root of a server installed on your local computer (most likely IIS).
12.2 You can transform Site-Root-Relative paths to Local paths.
12.2.1 To test your menu locally:
  • When you transform site-root paths to local paths, flyout menus would work correctly, regardless of where your Local Root Folder is located.
  • To continue with the example above, imagine that your Local Root Folder is W:\MySite\
  • The drive path to the script file is now W:\MySite\Pluginlab\Scripts\PLHFO.js
  • The site root-relative path to the script file generated by the menu extension is /Pluginlab/Scripts/PLHFO.js.
  • When you test the page in a browser, the Pluginlab Path Adjustment Feature transforms the site-root-relative path for the script file to the local path W:\MySite\Pluginlab\Scripts\PLHFO.js.
  • The script file can be found without a hitch, the flyout menu should display properly.
12.2.2 To test your menu on the Web server:
Upload all of the contents of your Local Root Folder directly into the site root on the Web server or into the root of a server installed on your local computer.
12.3. You can transform Site-Root-Relative paths to Document-Relative Paths.
  • In this case, flyout menus must always work properly on a local computer and on a Web server, regardless of where your Local Root Folder is located.
    For example, on your local computer, you defined your site in Dreamweaver to have a Local Root Folder called MySite in the root of drive W:\, and your current document is located at the site root level.
  • The drive path to the script file on your computer looks like this: W:\MySite\Pluginlab\Scripts\PLHFO.js
  • The site-root-relative path to the script file generated by the menu extension is: /Pluginlab/Scripts/PLHFO.js
  • The Pluginlab Path Adjustment Feature transforms the site-root-relative path to document-relative: Pluginlab/Scripts/PLHFO.js
Learn More:
Read more about script file in Learning About the JavaScript (.JS) File.
Read more about path names in Understanding Path Names.
Read more about defining a site in Dreamweaver in Defining a Site in Dreamweaver.

Expand/Collapse  13. Why am I not allowed to edit my menu?

You have once created a flyout menu, and now need to modify its structure or style settings. You have opened the HTML page containing the menu and run the relevant Menu Extension.
Under certain circumstances you might be wondering why your menu structure is not loaded into the extension. There are several possible reasons you are not allowed to edit the existing menu:
13.1. You may have edited the HTML code generated by the extension directly in Code View in Dreamweaver.
For example, if you change the comment in the script tag below, the script file is corrupted and the menu structure cannot be loaded into the extension.
The only solution is to restore the HTML code modified manually.
13.2. Probably, you have manually moved the .JS file to a different location.
13.3. You may have moved the HTML page to a new location and not updated your document-relative path to the script file.
Here is a common solution for the cases listed above:
Reopen the HTML page and the menu extension.
Expand the Save/Load area on the Setup Tab.
Use the folder icon in order to browse and select the proper .JS file as it is shown in the screenshot below.
Simply load your menu from the script file.
If your flyout menu contains images, that are linked to by document-relative links, most likely, you need to update those links from within the extension.
Note:
Always use the Pluginlab extension to move or rename a script file. Everything you need to modify your menu can be done from within the extension. The script records and saves those changes. In addition, we recommend that you accept the default file name and location for the script file.
13.4. Just one more reason is very common when co-workers are developing a site.
Very likely, your flyout menu was developed by using a later version of the Pluginlab extension, than the one, you have opened to modify its structure or style settings.
Download a new version of the extension from the PluginLab Download Center.
Learn More:
Read more about script file in Learning About the JavaScript (.JS) File.
>Read more about path names in Understanding Path Names.

Expand/Collapse  14. How to enable the Add/Update button in the Update Pages dialog?

The Add/Update button is enabled only when Menu Position -> Use Absolute Position on Page option is turned on.
This is known as absolute positioned menus. Otherwise the extension has no way of knowing exactly where you have placed the menu on the new page.
It is possible to use a DW template instead if you don't want to set absolute positioning.
Learn More:
Read more about updating menus in Update a Menu Across a Site.

Expand/Collapse  15. Is the cross frame functionality applied to the Pluginlab Menu systems?

No DHTML / HTML objects can cross frame borders in pure sense of the word. The HTML / DHTML objects can only belong to a single window / frame and can't appear above borders or go beyond them.
Though it could be possible for us to try to incorporate cross frame functionality into our menus, we don't think this would worth the effort.
The design of our menu system allows eliminating the whole need of a separate frame for the menu, as the menu itself can be easily placed and updated through multiple pages via Update Pages dialog or Dreamweaver template.
The menu functionality and structure is stored in a shared .js file which means that clients will only have to download it once. This leaves no advantages to the frame design.
Furthermore, if you design your site using frames, you will have to face all the drawbacks of this approach:
Such as poor search engine indexing
Problems with browsers history
Bookmaking of pages by users
Problems with elements unable to cross the frame border, etc.
Unless you have a strong reason for placing the menu to a separate frame, we don't recommend this approach for our menus, also a separate frame is simply not required for our menus. Now days all browsers fully support layers so there is very little need to use frames.

Expand/Collapse  16. How can I let the menu to be on top of a flash presentation?

This is not related to our menus but rather a setup which is need in flash.
To allow the layering of Flash content with DHTML content you have to do the following with the Flash Object tag:
  • Add the following parameter to the <object> tag:
    <param name="wmode" value="transparent">;
  • Add the following parameter to the <embed> tag:
    wmode="transparent"
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_14201
For example:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab
#version=6,0,29,0" width="560" height="280">
    <param name="movie" value="file:///C|/Inetpub/wwwroot/test.swf">
    <param name="quality" value="high">
    <param name="wmode" value="transparent">
    <embed src="file:///C|/Inetpub/wwwroot/test.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="560" height="280" wmode="transparent"></embed>
</object>

Expand/Collapse  17. I have copied over a web page with a menu from one computer to another. Why is the menu not working?

There might be several reasons why this is happening:
First of all you have to make sure that you have copied all the pages and all the script files that are used in them.
Then please check the local root folders (for this go to Site > Manage Sites > Edit... > Local Info). Pages and script files of new menus should have the same position relative to the site root as the old menus (please note that the directory name should be identical for both old and new menus).
And finally you need to check your path adjustment settings. If the site-root relative path is selected as Transform to local path, you need to update the existing pages using the Update Pages button.
Learn More:
Read more about path names in Understanding Path Names.
Read more about defining a site in Dreamweaver in Defining a Site in Dreamweaver.

Expand/Collapse  18. I just upgraded the extension and now my existing menus do not work anymore. How do I fix this?

Here are the possible reasons why it can happen:
18.1 The path to the menu script file is not defined correctly.
In this case please check the paths.
18.2 The script is not in the stated folder.
Please make sure you don't forget to place your menu script into the right folder.
18.3 Previously you've been experimenting with different menus, and there is still the onload call for the menu that doesn't exist on the page.
For example:
  • You inserted two menus on the same page (i.e. Vertical and Horizontal)
  • Then after awhile you deleted manually one of the menus (let it be the horizontal menu).
  • You removed the H menu from the page, but the onload call for this menu in the body tag wasn't deleted.
  • Your V menu worked fine, as the first call in the onload was for vertical menu.
  • You updated the menu, and your V menu stopped working. It happened because onload calls changed, and the recent/updated one took the last place.
  • Now the first onload call (for H menu) fails, this results in error and stops the second onload call (for V menu) from executing. The scenario is not executed and the menu doesn't work.
    What you need to do in this case is to open the Horizontal menu extension and press the Delete button. This will remove the horizontal menu call from the onload in the <body> tag.
Note:
The only correct way to delete a menu from the page is thru the extension dialogue by pressing the Delete button.
Learn More
Read more about script file in Learning About the JavaScript (.JS) File.
Read more about path names in Understanding Path Names.
Read more about updating menus in Update a Menu Across a Site.

Expand/Collapse  19. I installed the extension, but the extension icon is disabled. Why?

When installing the PL extensions with the help of the MM Extension Manager, the message "The extension has successfully been installed" confirms the extension installation. After the process is completed, and you start Dreamweaver the only one reason why the extension icon can be disable is that there is no current files open in Dreamweaver.
Please make sure you open the page (new or already created) and then insert the menu.
Your Account |  Store | Contact