Recent Posts

I just realized, that within each subsite there are literally thousands in some cases of internal hyperlinks in the format <a href="BlueWidgets.html"> that would also be affected by any structural changes.

Thank you for your detailed response!

My site started out 12 years ago as 7 little pages, but quickly grew to the point that it is now over 14,000 (all manually created). Back when Frontpage was still supported, as the site grew I began experiencing problems with the navigation. I called Microsoft and they told me I needed to make subsites, which I learned how to do. It solved the navigation problem immediately, because each subsite had it's own navigation structure as if it was a stand-alone site.

The issue that arose was that I could create an internal hyperlink from the top site, to a subsite with the direct reference like <a href="subsite/BlueWidgets.html">; however, I could not create an internal hyperlink from a subsite up to the main site, or to another subsite. So, I quickly learned to just use the full url in ALL my hyperlinks: <a href="hxxp://www.mystite.com/subsite/BlueWidgets.html">. That way I never had to worry that a link would be broken no matter where I used it. So, the site has a lot of a full url hyperlinks.

The main reason for creating the subsites in the first place was the issue with navigation. Frontpage could not handle all the files as one big site. I'm totally clueless as to how the navigation will be when I move to Dreamweaver since I haven't purchased it, and learned how to use it yet. Right now in Frontpage, I just move files where I want them in the Navigation screen. With all these files it would be a nightmare if suddenly the subsites when from being hxxp://example.com/blog/ to hxxp://blog.example.com/ because of all the references on the Internet in the search engines and where other sites have linked to my site.

I guess I should have been more explicit when I asked my question to begin with. Will I be able to keep the subsite navigation? I already know that if I convert the subsites back to folders, I'm going to lose the navigation in the subsite immediately. One of the subsites is over 2000 pages, and I can foresee that subsite alone would be a nightmare to fix if I lose the navigation structure.

I can see where I can save myself a lot of time converting the webbot includes to PHP thanks to your wonderful article. If I could just figure out how Dreamweaver will handle the navigation of the subsites and that I will somehow be able to keep all my urls in tact in the hxxp://example.com/blog/ format, I would feel more confident of getting rid of Frontpage and switching to Dreamweaver. In the alternative, would I be better off switching to Expression Web? Since it is a Microsoft product, would it know better what to do with the subsites?

[dir]

The most important safeguard against disaster is to make a backup copy of your entire FP2003 site before you begin, and never delete it. That way, you can freely try out the Dreamweaver changeover. If anything goes wrong, start over with a fresh copy. 

The little globes on your FrontPage folders are an indication that Frontpage has configured them in Windows as "System" folders. In Windows Explorer, if you click View > Choose Details... > and enable the Attributes column, you'll see an "S" in the column.

That classification is a nuisance sometimes (a dir command in Command Prompt by default doesn't show the existence of System folders, and to enter it, you have to know it's there or use dir /as, and if I recall correctly, sometimes search programs aren't allowed to enter System folders to search their files).

If the System classification seems to cause any problems in Dreamweaver, you should be able to remove it using the DOS attrib command, something like

Code:

ATTRIB -S C:\[full path to your website folder]\foldername\

For help, in Command Prompt:

Code:

ATTRIB /?
or
HELP ATTRIB

I've saved the most difficult question for last, as I have no experience at all with FP subsites. After some research, the best sense I can make of it is this:

An FP subsite is a way of managing what other people call subdomains, from within FrontPage. It allows you to access
hxxp://example.com/blog/
as
hxxp://blog.example.com/

When using the FrontPage Extensions (FPE) on the server, they take care of the mapping of incoming requests to the correct subfolder of your website, because you've already configured it in FP.

It appears that the more common, non-FP, way of managing a subdomain is to just publish it as a folder of your main site, and then configure the mapping of example.com/blog/ to blog.example.com in your webhosting control panel.


It looks like you have two options for dealing with your current subsites. If it were me, I'd probably try them both, knowing that I could revert to my backup copies and start over if anything goes wrong. 

Option 1) Don't do anything special in FrontPage prior to importing the site into Dreamweaver.

I suspect Dreamweaver will not know or be able to detect anything about the status of the subfolders as subsites, and all links between your subsites, or between a subsite and the main site may be considered broken because blog.example.com is unknown. That probably can't be resolved until the site(s) are live on the server and the subdomain configuration is fully set up. Even then, Dreamweaver itself will probably always consider the links broken (or at least not recognize them as local links).

I don't know what other problems you might encounter.   


Option 2)

"Convert your subsites to folders" in FrontPage prior to importing the site into Dreamweaver.

FrontPage will give you some warnings about the consequences of doing this. Consider them carefully because they should give important clues about what problems you might encounter. Then go ahead and do it anyway because this is, after all, an experiment to see what problems arise. 

I suspect FrontPage will, as it often does, globally adjust links (and the interlinking, if any, between subsites) so that the sites refer to each other as just pages in separate folders of the same website, not as separate subdomains. It might make other adjustments, too, which hopefully it will have warned you about in advance. 

Each subsite will probably lose its theme and all other FP characteristics that it had that were different from the main site. That is, it's being merged into the main site.


The goals of these experiments would be to discover

a) Which method does not corrupt the site/subsites (or at least corrupts them the least) and makes them easiest to work with in Dreamweaver.

b) Which method works properly on the live server after subdomains are properly configured.

c) Choose the best.

Hopefully, one of the methods will work so well that it is obviously the right one to use.

With either method, if your subsites have FP password protection (enforced by the FPE), they'll lose it, and you'll need to apply new password protection at the server level, such as in cPanel > Password Protect Folders.


As mentioned, I've not done this type of conversion myself, but I hope that is at least accurate enough to help foresee some of the potential issues.

First of all, thank you so very much for all the work you've done creating your helpful website!

Unfortunately, I'm still living in the dark ages using Frontpage 2003 for my 14,000 plus page website. I've known for a long time that I need to move to something else and have pretty much decided to switch to Dreamweaver. I am so grateful that I found your site and the excellent articles.

Although I have never used the Shared Borders because I learned early on they were unreliable, I have used a lot of webbot includes. Having read your article How to replace FrontPage included content webbots with PHP ..., I can already see that I am going to be able to save myself a lot of headaches by converting all those includes to PHP before making the transition from Frontpage to Dreamweaver.

In searching your site, I have one concern that I have not been able to find the answer to, and that is that I have used "Subsites" extensively ... to the tune of over 80 of them. I can't seem to find anywhere how my subsites in Frontpage 2003 would be handled by Dreamweaver. In Frontpage, I think the Frontpage Extensions do something to the folders, changing them from regular folders to ones with the little globes on them. I just want to make sure that if there is anything I need to do before moving over to Dreamweaver to prevent any unwanted consequences.

[John]

John, thank you for your suggestion. I can see that the information would sometimes be useful, but to make it a built-in feature would make this already complicated script even harder to use.

Finding files modified within a range of dates/times could be quite useful (and I'll deal with it below), but it's not directly related to whether the files actually do contain suspicious snippets, which would already be caught by the searches that the script currently does.

Excluding files that you have already edited isn't necessarily as safe as it sounds, because the files could have been re-hacked since you edited them. If they're really clean, they shouldn't be listed in a new suspicious snippets search (except for any false positives), so they shouldn't have to be excluded.

----

But it is possible to add file timestamp checking into the PHP code. One place you could do it is in the BuildFileList() function, to make a file be either excluded or included based on its timestamp. Or you could create a whole new section of the script that first uses the current BuildFileList() to build the file list normally, and then output a report based on the timestamps of the files.

Although I don't want to add the feature to the default version of the script, I have created the following example code that shows usage of the key PHP functions that you'd probably need for adding a timestamp checking feature to your copy of the script. This code outputs a message if the file's timestamp falls within the "suspicious" range:

# You must either set this explicitly or endure PHP warnings about it.
# Make sure the timezone you specify IS the one the server is using for file timestamps.

date_default_timezone_set('America/Los_Angeles');

# Use exactly this format for your timestamps because
# it is the same format used below in the date() function.

$TimeRangeStart = "2012-04-01 05:00:00";
$TimeRangeEnd   = "2012-04-06 19:30:00";

# You'd normally get the filename from a list...
$filename = 'test.php';

$lastmod = date("Y-m-d H:i:s", filemtime($filename)); 
if(($lastmod >= $TimeRangeStart) && ($lastmod <= $TimeRangeEnd))
{

echo "Suspicious timestamp: $lastmod " . realpath($filename) . "\n";

# AN ALTERNATIVE, FILENAME ONLY.

#echo "Suspicious timestamp: $lastmod $filename\n"; 

# OR, IF IT IS FOR OUTPUT ON WEB PAGE, CLEAN AND COLORIZE THE TEXT:

#echo CleanColorText("Suspicious timestamp: $lastmod ", 'red') . CleanColorText(realpath($filename), 'black');

}

----

On a linux server, it's also possible to use linux commands directly to find files modified within a certain time range, and it's possible to use PHP to launch those commands and display the result. The key is the linux "find" command, described in detail at http://linux.die.net/man/1/find

This is an example of some prototype code, but I can't really recommend using find or using PHP shell_exec unless you're comfortable with them already. Nonetheless, it is an available method for those who want to do some exploring, studying, and experimenting:

# FIND REGULAR FILES MODIFIED WITHIN THE PAST 10 DAYS
$cmd = 'find ./ -type f -mtime -10';

$result = shell_exec($cmd);

# CLEAN RESULT FOR OUTPUT ON WEB PAGE
$echo htmlentities($result, ENT_QUOTES);

Some additional suggestions for the conversion process:

When rewriting a function call or a piece of code to newer methods, search all your source files for similar code to see if you can do all the conversions in just one or a few operations. This can be even more efficient if your editor supports regular expression search and replace in multiple files at once. Be careful with regex search/replace. A mistake can make a mess quickly, so make frequent backups that you can revert to.

If you can use .NET in your new project, it's a huge library that seems to have about everything under the sun, and all its documentation is online, so web searches are a good way to find replacements for old methods when you're not exactly sure what it is you're looking for. Search for what you want to do, along with the keyword ".NET".

I've been using the script to clean out a hacked joomla site, and I'm wondering if it would make sense and be possible to add a date range option in the file selection so that if you know when a hack occurred you could use it to look specifically at file changed from the date of the attack onwards, and / or be able to exclude files edited after a specific date, ie excluding ones you know you have replaced / corrected during the clean up process. ?

Thanks

John

Roger, thank you for taking the time to share your discovery. It probably will help someone.

Iwriteit2,
I and probably a lot of others, would sure like to know how you do it.  How did you pick the 20.  Is there a plan or a guru to follow that trades like you do?  May be a book? Any help is appreciated!

I've managed to convert the Amazon code so that it validates as valid HTML 4.01 strict. I did this by changing the <iframe> to <object>. An example of the code that works (newlines inserted for legibility) is:

Code:

<object data="http://rcm-uk.amazon.co.uk/e/cm?lt1=_blank&amp;bc1=78AAD5&amp;IS2=1
&amp;bg1=78AAD5&amp;fc1=FFFFFF&amp;lc1=C7E0F0&amp;t=<?=$associates_id?>
&amp;o=2&amp;p=8&amp;l=as1&amp;m=amazon&amp;f=ifr&amp;ref=tf_til
&amp;asins=<?=$asin?>" type="text/html"></object>

The corresponding CSS is:

Code:

div.book object {
width: 120px;
height: 240px;
border: none;
overflow: hidden;
float: left;
margin: 1ex;
}