SS V2.70f (and probably Web Engine too). The symptoms are a few to many page links made with the Text Editor > Link Editor apparently randomly changing to point at other pages. This problem afflicts larger projects, and when it hits can cause a lot of grief.

Below are some references to this in previous threads, but until now nothing really conclusive.
http://virtualmechanics.infopop.cc/eve/forums/a/tpc/f/1246038591/m/9001089681
http://virtualmechanics.infopop.cc/eve/forums/a/tpc/f/1...6063044?r=8406063044
http://virtualmechanics.infopop.cc/eve/forums/a/tpc/f/8...1097091?r=7181049091
http://virtualmechanics.infopop.cc/eve/forums/a/tpc/f/1...1010842?r=8871010842

Thanks to ReeceThomas (last thread) who sent me a project file, I now have something recreatable, which looks highly suspicious. To recreate the problem on a small scale, follow these steps:

Using SiteSpinner V 2.70f, open the tutorials project (a known good larger project)

Delete the second page ("BigPicture") with the Page > Page Delete command

Preview all with the double arrows

In preview, open the "Creating Curvy Shapes (Curvy)" page and scroll to the bottom

The link that says "See also Buttons Tutorial" now points at the Bookmarks page (was Buttons)

In Preview open the "Creating Straight Shapes (Straight)" page and scroll to the second paragraph

The link that says the "The curvy shapes have their own page" now points at the LayoutCen page (was Curvy)

About one third the way down the link that says "See also: Buttons tutorial" now also points at the bookmarks page

At the bottom the link that says "See also: Tutorial: Curvy Shapes" now also points at the LayoutCen page (was Curvy)

Also of interest is another "Curves" (=Curvy) link about halfway down the page, which hasn't been corrupted.

I've tried to find some sort of pattern to the corruptions, even tried to add some extra links before the page deletion. The only pattern I can find is that each time a corruption occurs, the changed link points to one page further back the page creation order. I'm assuming that the single page deletion is responsible here.

In Reece's project, of 200+ pages, a single page deletion like this produced 6000 extra corruptions -- many of them being common links. There were already some corruptions in the file -- three navigation links included on each page pointed six pages back in the page creation order. I still have that file and can forward that file to the folks at VM if it will help.

A reasonable workaround for now is not to delete pages from your project. Rather just shift them to say the end of your project, and recycle them as you require new pages. I haven't actually tried this, but expect it will work.

Afterthought:

When you delete a page, all the pages after it in the page creation order are moved back by 1. This means that associated images for those pages get new numbers. E.g, an image originally named obj3090geo1271pg37p6.png will become obj3090geo1271pg36p6.png -- exactly the same image but a new name, now on page36 instead of page37.

In turn, this means that when you republish one of those following pages, even if it is only a minor text change, you will also need to upload the new associated images. This affects only separate FTP uploads. If you use the built-in SiteSpinner FTP, that uploads all images again automatically anyway -- so it's not a problem in that case.

So even without the bug, as a separate FTPer, unless I was planning to upload everything again, I wouldn't delete any pages.

Bruceee...I'm wondering if deleting pages in my project is causing all the problems I'm having with links in IFrames? I still can not get them to work. Also, when I click on the double arrow to preview, the first time I click it will often point to the wrong page. When I go back to try to preview a second time it will go to the correct page.

Believe it or not I still cannot get the page in the IFrame to change to another page either. I worked on it most of the day yesterday. I get an error message or it goes to the page all right but not to the page in the IFrame where I want it to be.

I'm wondering if all my changes have made things progressively worse. It's an awful thought but is there a way I can start over without starting from scratch?

Bruce,

Very good research!

I think a better solution would to be not to use [page] type links. If I go into the tutorials Curvy page and change the Buttons link into an explicit html page link (i.e., button.html), there is no link corruption when the Big Picture page is deleted.

Of course, deleting a page will always cause the generated objects to be renumbered - no way around that. But if most of us use the built-in FTP, this is not an issue. For separate FTP'ers, publishing locally to a "clean" folder will gather the correct files to be uploaded.

So is what you're saying "move all your pages that have not been deleted from the Page Editor to a differently named ims folder? What are the steps I need to make to do this?

Yes, good job Brucceee.

This seems to be a variation on 'case C' in the original 'Links changed' report. That is, renaming a page that is being linked to and deleting a page that is before it in the internal page order.

It only seems to be happening with links in text objects.

We are looking at this now and and hopefully can find a simple workaround. I will let you know what we find.

Nan: Bruceee is probably more familiar with your situation but I suspect that this bug would not be affecting your iframes because it would not affect any new links that you create after deleting pages.

Nan,
I'm suggesting that instead of deleting old pages in your project, you just reposition them in your project using the Page Editor > Page Select > Arrange button. Rename them too if you wish.

In my testing I have found no problems at all with the Arrange feature, or renaming pages, so believe you can use those features freely. Then when you want a new page, strip out the content of a "deleted" page, and reuse the shell of that one as the base for your new one.

Just be very careful with the Delete Page function. Than can upset existing page links having nothing to do with the deleted page. It won't upset new page links. As Larry said, you can also avoid page links altogether, but they still have some nice other features, like responding to page renames, and removing most of the chances of typos.

Nan, your i-frame problem seems like a separate issue, so I suggest continue that in one of the other threads, or start a new one if you think it appropriate. It is most unlikely that you will have to start over

Harpo: thinking some more about this problem:

Would it be possible for SS to make the page deletion a pseudo deletion? I.e, cut all content from the page but keep the shell of the page hidden, but still occupying its original number in the page creation order. Then when we request a new page, reuse the pseudo deletion under its old index number?

This should fix two problems:
the page deletion bug -- there is no index number to change
the image renumbering issue -- images in subsequent pages don't require new numbers.

I'm just raising this as a possibility -- there may be practical reasons why it is completely impractical

Here's an off the wall suggestion: see how your competition solves the problem.

Ok,this if what I have found out:

This does seem to be caused by deleting a page after renaming pages that occur later in the internal page order.

It only seems to affect 'page:' type links in text. 'Page:' links on objects are okay.

Unlike Stevo's case C bug (renaming a page after deleting a page) previewing all pages between deleting and renaming does not appear to prevent the problem.

(BTW. Note that Most of Stevo's bug was corrected in SS ver 2.7d but if text links are used in case C or this new case, there is still a problem.)

The problem can be reversed by:
- renaming the renamed pages from their new names back to their original names
- previewing all pages
- saving the project and reloading it
- renaming the renamed pages back to their new names

So in Bruceee's example using the tutorial project (after deleting page 'BigPicture' to create the problem):

- rename the pages 'Button' to 'Buttons' and 'Curvy' to 'ShapesCur'
- preview all pages (or just the pages that have links to these renamed pages if you know which ones they are)
- save the project and then reload it
- rename the pages 'Buttons' to 'Button' and 'ShapesCur' to 'Curvy'

Now all the links should be correct.

You can see the old page name for a misbehaving page type link by looking at its link code in the text editor using 'expand hyperlinks' (but don't edit the expanded page type links by hand).

Bruceee, if this doesn't seem to be what you see in Reece's project, can you send me a copy of it? If you do, can you tell me which page you deleted to create the errors.

We should be able to correct this bug in the same way we fixed it for links in objects in 2.70d.

Again, thanks Bruceee for spending the time to isolate this.

Thanks Harpo, that's starting to make sense now. As a test, following your steps, I have been able to reverse the corruption in the tutorials project. That was the easy one

I expect those steps will work too with Reece's project. But in order to undo the renaming, I have to first figure out what the original names were.

If my understanding of this is right:
1. I can pick up the original page names by looking directly in the .ims project file with a hex editor -- I see ASCII text there of the form <a href="page:// 56:data_quality"> which are just expanded hyperlinks.

2. I can get a list of files sorted by creation order by doing a Preview All and then by sorting the preview folder html file in reverse order. Preview all works backwards from the last page created.

If those assumptions are wrong, I'll find out tomorrow -- oops, it's tomorrow already

Yes, that is correct. The latter assumes sorting the files by date modified.

First of all, thanks to Brucee, I really think a new designation should be invented for you, How about 'Emperor of the Forum' or some such. I do want to stress, the danger of this bug is that it may not me noticeable to the user for a long time after it manifests, I'm very happy to see it looks like there is a way to reverse it (not for me, I have long since bit the bullet, the site now is being maintained with code, includes for all links,external CSS and a content manager (something I really should have done from the start, SS was probably not the appropriate vehicle for this particular project,it was originally envisioned as a much less ambitious one, and both myself and client are comfortable hand coding (I'm not any kind of web designer, more of a content provider, the web work is kind of just a corollary.) But dang-nabit, SS is SO easy and fast...

Anyhow, I'll sure continue to use SS for the smaller projects, and I'm hugely gratified to see this response from both Emperor Brucee and SS staff.

I don't know if there is any way, maybe a emailing to the registered users, to alert them of this, because it can potentially have disastrous ramifications ( I just thank God for an understanding client.) If an issue happens with industry standard tools, it's defendable, if you're using an alternate solution, you are in a much less defendable position

Once again, my kudos to SS Staff, and, most of all, to Emperor Brucee. "All Hail the King!"

I agree about notifications. I would rather no about a problem than find out the hard way.
Also, I did not know there was a new version and it would be cool if users were notified when new versions come out. I'd love to see an Update notification like I get with other programs. Like with Acrobat, it lets you know if there is an update automatically when you open the program. Also, please note Harpo that I stated a couple days ago that the bug affected image links and now I remember it did not. Only text links were affected. PS: That Brucee isa swell fella...always pitches right in with solutions.

Thanks for the kind words guys Working off Harpo's repair scheme, I have been able to repair Reese's project. A few pointers for anyone else repairing a large project:

1. If you can remember the old names for your pages, then skip this step completely. If you can't, read on.

Scan the project ims project file for links of this form: <a href="page:// 56:data_quality"> which are just expanded hyperlinks. This will net you two things:

the index number the page had when you made the link. Don't rely on the index number to be permanent -- because it will change as pages are deleted. It does not change as pages are added -- they are added to the end of the list. Nor does the page sort order affect this index.

the name the page had when you made the link. You will very likely find duplicate names if you have made links to the page while it had other names.

I used a standard search and replace program working directly on the .ims project file to extract all the names and numbers, but many text editors will help too. Even Notepad, and the SiteSpinner text editor (with hyperlinks expanded). Again, use the .ims project file directly in the text editor.

2. Open your project in SiteSpinner and use the Page Editor > Page Select tab > Arrange button to open your page list. Even though it is not obvious, you can drag the right and bottom edges of the window to resize it. Now work through the list, renaming the pages to the names you discovered in step 1. Watch for capitalization and oddities like trailing spaces -- your object is to get the names back to exactly as they were. To select a page for renaming, click twice on the page name, slowly. Or use the Rename button at the bottom of the window. You can rename pages other ways too, but I found this one best for a big project.

If you have two or more names for a page, use the the first name you have.

3. Save your project, then preview all, and save again. This last save makes the corrected page indexes part of your project. At this point you should find the link corruption is now greatly diminished.

4. For pages with multiple names, go back and repeat steps 2 and 3. For pages with two or more names, use the second name from your list. For pages with three names, repeat using the third name from the list and so on.

5. Your project may not yet be completely free of corruption. So open the individual link in the Text Editor, expand the hyperlinks and look closely at the original page name -- the bit straight after the index number -- that is the page name the target page must revert too. When you have found all the bad links and the original page names, make a final pass through steps 2 and 3.

New versions of Web Engine and SiteSpinner will likely have this bug corrected, so you will never need this repair. But if you are caught with an old version and suffer the page link corruption, this is the way out.

Does this hold true for smaller projects? i.e. under 50 pages?

Yes. It should be easier. You will more likely remember your old page names, and can probably rename pages from a drop-down page list.

Hi Stevo,

Right now, for new versions notifications, you can subscribe to the News and Announcements forum. We always annouce new releases there.

To subscribe, just go there, click on the 'Notify' button, choose 'Immediate Notification by Email' and press 'Update My Notification'