locked
DWT page and updating RRS feed

  • Question

  • Hi all,

    I am finding that when I go to update a large number of pages (close to a 1000), that I the update doesn't alsways work correctly. 

    My question: is there a way to update a dwt page in batches so that I can check to make sure that they are all updating correctly?

    Thanks,

    Peter

    Tuesday, May 14, 2013 11:48 PM

Answers

All replies

  • You could try opening or highlighting a group of pages  Format > Dynamic Web Template > Update Selected Page and see if that works.

    pat


    Pat Geary - Microsoft MVP

    Expression  Web Tutorials & Templates | Expression Web Blog | Migrating from FrontPage to Expression
     - Free EW Community Toolbar - Free Site Templates

    • Marked as answer by Petersocal Wednesday, May 15, 2013 1:25 AM
    Wednesday, May 15, 2013 1:07 AM
  • Geez, 1000 pages!! DWTs were never meant for sites of that size. Not only do page updates become problematic, every single page has to be republished every time you make a template change! You really, really need to consider switching to a server-side include templating solution.

    Personally, I prefer PHP includes, which are directly supported by EW, over SSIs. Either one will require you to establish a 301 redirect from ".html" to ".php" (or ".shtml" if you go with SSIs), but that is easily done.

    For each of the common areas currently in your DWT, usually header, footer, nav (and any other common areas you may have, although those are the most common), create an include file and use "Insert|PHP|Include.." (or "Require") to include it in the DWT. Once all of the include files have been created, and added to the DWT, and propagated to all attached files, you can stop using the DWT. From then on, when you change an included file (usually nav, when pages are added), you publish ONLY that file to the server, not the whole site. The included content will be added to the page when it is rendered to the browser.

    This has tremendous advantages. Obviously, you no longer have to wait while the whole site propagates the update, nor while the whole site is republished. Changes to one include, say, navigation, only affect that include, and only that include file need be published, since it is added to the page when the page file is sent to the browser for rendering.

    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 Wednesday, May 15, 2013 1:15 AM
    Wednesday, May 15, 2013 1:08 AM
  • Thanks Pat
    Wednesday, May 15, 2013 1:25 AM
  • Scott...

    Yeah... I know it is a really bad way to do it...and some day I am going to have to change...but for now it works...  

    The pages are all very simple, and I only change the template about once a year... 

    Thanks for the input, I will file your reply and use it when I change the entire site... :)

    Peter

    Wednesday, May 15, 2013 1:28 AM
  • Oh, well... only once a year...  ;-)

    Still, if you have to work your way through 1000+ pages, highlighting them and using "Format|Dynamic Web Template|Update Selected Page" to ensure you get them all updated, you could probably extract the common areas into includes in the time it would take to do that. It's not a terribly complex process, but... hey, it's your site...

    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.

    Wednesday, May 15, 2013 5:02 AM
  • Wow, that's a great idea.  Thank you!

    I'm just wrestling with this same issue.  Mine is s small site ( <12 pages).  I'm tempted just to rebuild it with EW4. Obviously, it's outdated, but I just kept making minor content tweaks.  I never liked having to update the DWT links to all the pages, if I made any changes there. 

    My only concern now, is that for reason my hosting site doesn't support EW.  They have their own app, and also support something called Zoomla?  This forum alone, is probably all I'd ever need for support.  I'm already in the process of downloading and purchasing the various pieces of tutorials and manuals.

    Peter

    Tuesday, September 1, 2015 9:25 PM
  • Your hosting service doesn't "support" EW, nor Dreamweaver, nor any other website creation program. That's like saying that some laser printer doesn't support MS Word.

    You create your site and upload it with FTP, which is the Web standard File Transfer Protocol that every standard host uses. There's no "support" involved. You could FTP your site with EW (best option), FileZilla, Wise FTP, FTP Commander, or any of a zillion other free FTP programs.

    Zoomla is overkill for a small site, has lots of limits, and a huge learning curve.


    A horse walks into a bar. The bartender asks "Why the long face?" "Because I was born into servitude and when I die my hooves will be used to make glue." It was at this point that the bartender realized he would not be getting a tip.

    Wednesday, September 2, 2015 3:10 AM
  • "My only concern now, is that for reason my hosting site doesn't support EW."My only concern now, is that for reason my hosting site doesn't support EW."

    The only way that statement could be true is if your host does not support FTP.    That would be a very rare host indeed, and you may want to drop them and find a real host, if true.  FTP is the only thing needed to "support" EW, and it is a standard feature of almost every hosting company, and is the standard method of uploading websites written in whatever tool you want.

    Wednesday, September 2, 2015 3:32 AM
  • What Bill said. You can write HTML and CSS in EW, Dreamweaver, Aptana, CoffeeCup, or Notepad (and many of us have at some point in our careers) or any other text editor, since they are basically simply text files. After that, you transfer (publish) your files to the provider's server using industry standard FTP, or, for some providers, using the File Manager software provided by the vendor.

    As for a DWT vs server side includes, with only a dozen or so pages your site is perfectly suited to a DWT. It is only when your site grows to hundreds of pages that site management with DWTs becomes cumbersome.

    BTW, the CMS that you're thinking of is probably Joomla, not Zoomla, and your site is far too small to need anything of that complexity.

    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.

    Wednesday, September 2, 2015 3:44 AM
  • Bill, Kathy, and Scott,

    Thanks for the quick replies.  I think "support" was the wrong term to use.  When I reached out to the host site's tech support, saying I was considering using EW as a replacement to Frontpage, I received a rather curt reply telling me that they didn't support "third-party software". Yes, it is Joomla, not Zoomla.

    It took me a bit of practice, but I think I've got both the local (computer hard drive) and remote (server) sites set up in my copy of EW, and I'm able to edit pages locally, then publish to the remote site. 

    I'm still having problems with my dwt updates, though.  After recalculating all the hyperlinks in EW, I see all the linked pages attached to the dwt (or is it the other way around?). I can publish changes to the DWT, and push updates to the other 23 pages, without having to open up all the pages.  Pretty cool.  But, it's not working quite the way I'd hoped.  I updated the hyperlink to one of the navigation buttons on the DWT.  After updating the other attached pages, the button properties are still pointing to the old page (I was using an "updating page" link, while creating an updated page).  So, I've still got some homework to do.

    Thanks again to all!

    Peter

    Wednesday, September 2, 2015 1:22 PM
  • I think that you don't quite have a handle on how a DWT works. In the DWT file itself, the "master template," all regions not explicitly marked as "editable regions" will be duplicated (and changes updated) in all files attached to it. This will normally include headers, any top or sidebar navigation, and footers—content that should be the same on all pages. That way, when you change your nav links in any of those areas, they are propagated to all attached pages.

    Any content within any marked editable region should be edited in the actual pages attached to the DWT. If you edit the content in editable regions in the DWT itself, those changes will not be propagated to attached pages. The idea is that those areas belong to the linked ages, and may be, and probably are, different on each page. That's how templating works.

    And that's what I think is happening in your case. Those edits that you made weren't propagated because they lie within an editable region. You will have to either move them to a non-editable region, or close the editable region they're in immediately before and reopen them following them in the source code to make them their own non-editable regions. I haven't seen your source code, so you will have to make that determination.

    So, remember, in the DWT file, everything in non-editable regions (i.e. anything not explicitly marked as editable) gets promulgated to all attached pages, while nothing in any editable region gets updated when changes are made.

    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.

    Wednesday, September 2, 2015 7:10 PM
  • Scott,  

    Thanks.  I'll take a closer look at what is defined as "editable and non-editable" in my DWT, but I suspect you're correct.  I shouldn't have been messing with editing the DWT, without understanding this distinction. I thought when we created the DWT, the nav buttons, headers, footers were all in non-editable regions. Everything else in the template is just empty space holders for content. 

    Scott, I didn't understand this sentence: "You will have to either move them to a non-editable region, or close the editable region they're in immediately before and reopen them following them in the source code to make them their own non-editable regions."

    Can you clarify what "immediately before and reopen them following them" means?

    Thanks for the help.

     

    Thursday, September 3, 2015 1:56 AM
  • Sure. Look at the code block below. Note that each editable region is set off by an opening comment and a closing comment. If you have a line (or a section) of code in an editable block that you want to make non-editable, create an <!-- #EndEditable --> comment immediately prior to that line of code. Then, immediately following that line (or section), create a new <!-- #BeginEditable "whatever" -->. Now the line (or section) of code has been removed from the editable region of which it was a part. Note that you will have created two editable regions from the original one, so the second will need a different name.

    FWIW, having to do this might indicate a somewhat unusual information architecture, so you might want to rethink your page in light of how DWTs actually work. Just a suggestion...  ;-)

    <!-- #BeginEditable "embeddedStyles" -->
    <style type="text/css">
    </style>
    <!-- #EndEditable -->

    <!-- #BeginEditable "pageLocalScripts" -->
    <script type="text/javascript">
        $(document).ready(
            function(){
                $('#testList').innerfade({
                    speed: 'slow',
                    timeout: 4000,
                    type: 'sequence',
                    containerheight: '220px'
                });
            }
        );
    </script>
    <!-- #EndEditable -->

    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.

    • Proposed as answer by PRSikes Thursday, September 3, 2015 1:04 PM
    Thursday, September 3, 2015 3:09 AM
  • " I received a rather curt reply telling me that they didn't support "third-party software""

    That simply means, as is the case for all hosting companies, that their support team is for hosting questions, not for questions about things they don't control, such as your website creation software.  No hosting company provides support help for EW, FrontPage, Dreamweaver, Notepad, or whatever else you are using to create your site.

    Thursday, September 3, 2015 3:21 AM
  • Scott,

    Really helpful.  Thank you!

    Peter

    Thursday, September 3, 2015 1:04 PM
  • Hi Kathy,  I agree.  They'll provide support for their own editing app, but not necessarily for design questions.  They have a full design team that is ready to field those questions ( for a cost, of course).  I thought they might be will to share opinions of the different editors available.  I've already made my decision to go with EW.  (Wordpress intrigued me too)  Joomla probably paid a fee for the posting of their download from the site's "recommended apps" page.

    Best,

    Peter

    Thursday, September 3, 2015 1:11 PM