locked
EW4 DWT's will not update attached pages RRS feed

  • Question

  • I am using EW4 SP2    When I update a DWT, it will not update the attached files.  If I open one of the attached files, and run Format/Dynamic Web Template/update attached pages or Update All Pages, the page that is open is updated. Works fine manually for each page but will not update all attached pages in my website

    I googled the problem and found three suggestions: 1) Make sure MetaData files are enabled for the site (they are)  2) run Tools/Recalculate Hyperlinks (I did) and 3) run FP Cleaner (I did)

    With all that, the problem still persists.

    I then moved the website to a backup folder. Deleted the file location and started and imported a new website from the backup data. Enabled the MetaData files, Recalculated the Hyperlinks, ran FP cleaner, just to be safe -- and the problem is still there.

    Is there a bug in Expression Web 4 that will keep the DWT's from updating automatically? If I have to manually do this for every page in the site  ;-(

    ? ? ?

    Paul

    Tuesday, January 29, 2013 4:25 AM

Answers

  • Problem Solved!

    I was trying to load a conditional statement at the beginning of the pages and I knew the DWT's were stumbling over it. For those curious, it is the IE compatibility statement that Paul Irish developed to deal with HTML5. The code had accompanied a template I was working on and I assumed it was good.

    I removed the statement and cleaned up the DWT's and the connections started working again. I am guessing the <!--end if--> statements in the code were creating some type of issue with EW4 or the DWT process.

    I had just about given up on the problem, resigning myself to have to manually update. Started addressing other issues instead and stumbled into this solution. Hope it helps someone else

    Paul


    Thursday, January 31, 2013 3:04 AM

All replies

  •  If I open one of the attached files, and run Format/Dynamic Web Template/update attached pages or Update All Pages, the page that is open is updated.

    If you actually mean that the way it sounds, then you misunderstand how DWTs work. The only page edits that cause all attached pages to update are edits to the .dwt file itself. This is by design. The common areas of the site, typically the header, top and side nav, and the footer, are contained in the .dwt file, and that is the only place they can be edited.

    When you edit an attached page, EW's interface will prevent you from editing those areas (the non-editable regions) in design view (you get a slashed circle if you try to click there), and if you edit them in code view, will warn you if you try to save the file. The only thing that you can edit in attached files are those regions designated as editable regions, and by design, those edits are meant for that page only.

    If you want something to be propagated to all attached pages, create a non-editable region in the .dwt file for it, and edit it in the .dwt file. When you save it, all attached pages will update. Otherwise, edits to those non-editable regions in attached files will be rejected, and edits to editable regions are intended to be local to the page, and not replicated to others. IOW, what you are seeing is the way that DWTs are intended to work.

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

    Tuesday, January 29, 2013 5:37 AM
  • I have had this problem all along as well. I edit the DWT ( actual DWT itself) but I can only update pages that are OPEN. I also tried everything to no avail. The work around has always been to open every page first.
    Tuesday, January 29, 2013 12:25 PM
  • Paul and Surferbob.

    Unfortunaltely this has been  known issue with DWTs since the FrontPage 2003 days.

    Paul, if you're running FPCleaner and removing the .WEB files "After" you recalculate hyperlinks,
    you're deleting the hyperlink info and need to recalculate again.


    Expression Web MVP


    Tuesday, January 29, 2013 1:35 PM
  •  If I open one of the attached files, and run Format/Dynamic Web Template/update attached pages or Update All Pages, the page that is open is updated.

    If you actually mean that the way it sounds, . . .if you want something to be propagated to all attached pages, create a non-editable region in the .dwt file for it, and edit it in the .dwt file. When you save it, all attached pages will update.


    Scott,

    Sorry I didn't make myself clear. The issue is I do edit the the parent region of the DWT, then it does not propagate to the child pages when I click the "update all". If I open the child page and then click update, it will accept the changes I've made in the DWT.

    Paul

    Tuesday, January 29, 2013 2:04 PM
  • Hmm... interesting. Although I have heard of this happening in some previous versions, I thought that it had been fixed in EW4 SP2 (or perhaps even before). I know that I have personally never experienced it in any version.

    Wait, something just occurred to me... are you working locally? Seems to me that I recall that someone tried to work remotely and something like this happened (in "grasping at straws" mode here ;-). AFAIK, DWTs will not work correctly under those circumstances unless you are using FPSE (and maybe not then—I haven't used the FPSE in 12 years, so wouldn't know for sure).

    OK, let's say that you are working locally, and you've already tried all the usual suspects (recalculate hyperlinks, etc.). In that event, let's try this—in the Folder List panel, select (Ctrl-click) all of the files that are supposed to be attached to the DWT. Then, click "Format->Dynamic Web Templates->Attach Dynamic Web Template." Browse to the DWT and attach it again. That should cause the metadata to update, and should cause all attached pages to update.

    If it does, now open the DWT, make a minor but visible change to a non-editable region, and save the file. See how many pages are reported as having to be updated, then come back and report how it went.

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

    Tuesday, January 29, 2013 8:46 PM
  • Scott,

    I am working locally. I tried your suggestions without success.

    1) Selected all files and "attached DWT"  8 pages were updated and when I opened the changes, all had the template as I had saved it.

    2) I then opened the the DWT (no other files open) and made an edit in the non-editable region. I saved the file and NO pages were updated. Went back to the files and sure enough, the edit had not been applied.

    3) with that page still open, I clicked on Format/DWT/Update all pages -- that one page that was opened was updated.

    4) went to the next page, it still had the old formatting. 

    The "auto update" portion of the DWT's does not work. I tried selecting all the files in Folder View and then Format/DWT/Update all pages and "0" pages were updated. This is right after I attached the template to the pages.

    Right now, the site has 12 pages in it and pretty easy to handle. But I am getting ready to add all the necessary pages and that count will go to around 50. It will be a monster to maintain.  ;-(

    Any other ideas?

    Paul

    Tuesday, January 29, 2013 9:13 PM
  • Where is your website located? The physical path on your computer.


    Free Expression Web Tutorials
    For an Expression Web forum without the posting issues try expressionwebforum.com

    Tuesday, January 29, 2013 9:45 PM
  • Good catch, Cheryl; I forgot about those UNC path issues. ;-)

    Paul, there have been issues reported in the past when UNC paths were used (//servername/path-to-resources). On those occasions, one resolution has been to map the target location to a drive letter, and use that drive letter instead. If you are using UNC paths in your site, you might try that approach and see what effect it has. Just a thought...  ;-)

    Of course, if you're not using UNC paths, I'm afraid that I am at a loss. I cannot replicate the issue, which makes troubleshooting it purely a matter of conjecture (like the above... ;-).

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

    Tuesday, January 29, 2013 11:06 PM
  • While I can't reproduce the issue - DWTs update fine for me - your last post does raise an issue.

    If you are using a DWT for a site that gets to around 50 pages, you would have to republish all 50 pages after each change to the DWT (even if the DWT was updating correctly).  It sounds like you may reach the point where server-side includes for the common content makes more sense than a DWT.  Using server-side include file(s), you'd update the include file, only, when you needed to make a change to common content, and the server would put the new content into each page as it was called for, without needing to republish them.

    This doesn't answer your DWT question, but switching to server-side includes now would by-pass the issue.

    Tuesday, January 29, 2013 11:16 PM
  • Where is your website located? The physical path on your computer.



    Cheryl & others,

    Path to my local site is: D:\My Documents\Cobra\Period Correct\Website  I am trying to edit it there.

    Paul

    Wednesday, January 30, 2013 12:11 AM
  • Curious,

    Are the components necessary for this to work a part of the files/dll's and associated data files or is it entries into the registry.

    I am curious if I were to delete the program and all files, and reinstall or is it a waste of time?

    I hate it when an advertised feature doesn't work -- especially when it is one you want to use.

    Paul

    Wednesday, January 30, 2013 12:16 AM
  • Paul, It looks like you are using a remapped profile, is that correct? If so, try a part outside your use profile. Particularly if this is a remap to a server share on a corporate network.

    l use d:\www and the www is not a local website. Each folder in the www is defined as a separate site.

    The reason I'm suggesting using a location outside of your profile is that some poeple have had issues when they use "subsites" in the My Documents\My Webs (or My Websites depending on OS version) because the OS marks that folder as a root web so any websites you create in it are actually subsites as far as EW is concerned and you need to have the meta data turned on for the entire www folder.

    I don't like having websites in a user profile not only because of some potential issues that have been reported but also because the larger your profile the longer it takes to boot. Besides the fact that I work on multiple machines and sometimes across the network to access a site on a different comptuer than the one one I'm working on. Sharing a user profile folder is generally not a good idea. Plus years ago I'd mirror my production hosting environment as much as possible which meant the physical path was never on the C drive.


    Free Expression Web Tutorials
    For an Expression Web forum without the posting issues try expressionwebforum.com


    • Edited by Cheryl D Wise Wednesday, January 30, 2013 3:04 PM expaned
    Wednesday, January 30, 2013 1:56 AM
  • Don't waste your time uninstalling it. That never helps (for any product, really).

    There could be a problem with your site itself.

    Did it ever update all pages properly?

    Is D:\ an internal hard drive or a partition (not a mapped network drive)?

    Try this: make a new site (use one of the EW website templates). Set up the empty website folder properly (I might put it on C:\ for this experiment), create the site from the template in there. Can you update the attached pages on that site? If so, your current site may be corrupted.


    Things Liberal Arts graduates gever like to hear:
    “…which means you are going first in Double Jeopardy.”

    Wednesday, January 30, 2013 4:13 AM
  • Problem Solved!

    I was trying to load a conditional statement at the beginning of the pages and I knew the DWT's were stumbling over it. For those curious, it is the IE compatibility statement that Paul Irish developed to deal with HTML5. The code had accompanied a template I was working on and I assumed it was good.

    I removed the statement and cleaned up the DWT's and the connections started working again. I am guessing the <!--end if--> statements in the code were creating some type of issue with EW4 or the DWT process.

    I had just about given up on the problem, resigning myself to have to manually update. Started addressing other issues instead and stumbled into this solution. Hope it helps someone else

    Paul


    Thursday, January 31, 2013 3:04 AM
  • Paul, if you are open to another approach, I prefer and use the "IEroot" method proposed over on "Position Is Everything." It works by creating a wrapper div (or divs) which is only seen by IE. By using contextual selectors with that div's id, you can include your IE-targeted CSS in your standard main CSS file. Most importantly, it does not bollox up the DWT mechanism.

    If you would like to see it in use, I employed it in this site. If you view the source, you will find this:

    <!-- Set a wrapper div seen only by IE6 for use in targeting CSS for IE6 quirks -->
    <!--[if IE 6]> 
    <div id="IE6root"> 
    <![endif]-->
    <!--[if IE 7]> 
    <div id="IE7root"> 
    <![endif]-->

    No other browser knows that that wrapper div is there. Later in the page there is a closing tag, again seen only by IE, to close that wrapper.

    Now, if you look at the CSS file, you will see eight or nine rules like this:

    #IE6root #clientList {
    	width:15%;
    	margin-left:60%;
    }

    Again, no other browser enforces those rules, so you don't need completely separate IE style sheets, and you can put your IE overrides following the "all other browsers" rules that they override, making for easier future maintenance, since you don't have the rules for the same element(s) scattered across multiple style sheets. That site was built using EW, and with EW's DWT templating, so I know that this method has no effect on the DWT mechanism. Oh, and if you check the markup, it is 100% valid, except, ironically, for the canned Better Business Bureau code required to display their seal. I didn't feel at liberty to alter that to meet validation. ;-)

    There are, of course, other approaches, but this one is simple to implement, easy to understand, and has no untoward side effects that I have yet found. Check it out. ;-)

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

    • Edited by paladyn Thursday, January 31, 2013 4:09 AM
    Thursday, January 31, 2013 3:59 AM
  • Scott,

    All of this deals with issues of older browsers and HTML5.  Your thoughts or comments on using HTML5 Shiv and/or Modernizr ?

    I am starting to get out of my "Pay Grade" - all of this has been a good learning experience.

    Really appreciate the support you and the group have provided. Wish all forums were this responsive.

    Thanks

    Paul


    Thursday, January 31, 2013 4:08 AM
  • Depends what you are trying to do with HTML 5. I'm using it now on the http://by-expression.cm site primarily so I can use the <video> element with a fallback to allow people to download the video for those with older browsers. I'm not using any of the other html 5 elements so it doesn't really make any difference to older browsers which will just render in quirks mode.

    So why are you wanting to use HTML 5? What are you trying to accomplish that can't be done in XHTML 1.0 transitional?


    Free Expression Web Tutorials
    For an Expression Web forum without the posting issues try expressionwebforum.com

    Thursday, January 31, 2013 4:38 AM
  • Hmm... not sure about the HTML5 shims/shivs, but from what I read of Paul Irish's article, "Conditional stylesheets vs CSS hacks? Answer: Neither!", the thrust of it was how to target CSS specifically to one or more versions of IE. The first two methods, conditional stylesheets (specific stylesheets linked only for specific versions of IE) and CSS hacks, which don't validate, he rejects, in favor of this "html classes" method.

    Now, we know that this method causes problems with EW's DWT mechanism. The method I described, by Hiroki Chalfant, does exactly that, does not interfere with DWTs, and meets all ofPaul's stated criteria:

    Conditional stylesheets mean 1 or 2 additional HTTP requests to download

    No additional stylesheets are involved at all, so no additional downloads.

    As they are in the the <head>, the rendering of the page waits until they're totally loaded.

    The wrapper div is only in the body element, and is only even seen by IE.

    Also – Yahoo's internal coding best practices do not recommend conditional stylesheets

    It does not involve any conditional stylesheets of any kind.

    It can separate a single CSS rule into multiple files. I've spent a lot of time wondering "Where the eff is that rule coming from!?" when it turned out to be tucked away in a conditional stylesheet.

    As stated earlier, a major advantage of the method is that the IE-only overrides can, and should, be placed in the same stylesheet and following the standard rules they override. That way, if/when you later modify that element, the applicable override is right there to be modified at the same time. No need to chase across multiple stylesheets to find and correct the IE override.

    Paul's article was basically saying that there is another alternative to conditional stylesheets and CSS hacks. I agree, and simply point out that there is yet another way than his "html class" approach, one which does not screw with DWTs. Basically, his method creates an ancestor class on the html element that can be used to target IE with contextual selectors. That is exactly what Hiroki's method does, except that the ancestor id is on an element that only exists in specific IE browsers.

    Paul's example...

    .ie6 div.foo { color: #ff8000; }

    is functionally identical to my example...

    #IE6root #clientList { color: #ff8000; }

    Both use a class/id that exists only for the targeted version of IE. Conceptually and operationally they are identical. The only apparent difference is that one of them hoses DWTs and the other doesn't. Your choice... ;-)

    cheers,
    scott

    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

    Thursday, January 31, 2013 5:14 AM