Folder Action not updating on site changes

Legacy ActionsDev
1

Has anyone else seen this sort of behavior? I have a simple Action to generate an Apache Type Map file:

function fwAfterEndHTML(){
	if(fwFolder.fwLastPage && fwPage == fwFolder.fwLastPage){
		var contents = fwFolder.fwItems;
		var pages = new Array;
		for (i in contents){
			var page = contents[i].fwFileName.toString();
			if( page.substr(0,6) == 'index_'){
				var lan = page.substr(6,(page.indexOf('.') - 6));
				if(lan != 'alternative'){
					pages.push( 'URI: ' + page + "nContent-type: text/htmlnContent-language: " + lan + "n");
				}else{
					pages.push( 'URI: ' + page + "nContent-type: text/htmln");
				}
			}
		}
		if(pages.length > 0) {
			makeVarfile(pages.join('n'));
		}
	}
}

This is applied to the root folder or a sub-folder in the site, and generates a text file with all index_language.extension files listed neatly in site order.

If I apply it to the site after all of these pages have been added, then all pages are listed. If I subsequently add a new page that should be listed, I have to force Publish Everything in order to see an update.

Is there a magic thing I can add to the Folder Action to make it realize there’s a new file? It’s a bit rough to tell the user “Hold down the Control key when you publish, or remove the Folder Action and add it back again whenever you change things around.” I thought the whole point of Folder Actions was that they didn’t need watching like this.

Thanks in advance,

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

2

Your frustration is understandable and your argument sound. However, the behavior you describe is advantageous from the viewpoint that folder actions act as as pseudo master-item for folders. Since folder actions are only really published when each of their child pages are published (they are not independently executed). They are also re-run for each of their daughter pages.

That said, here is a thought:

The function ‘fwIsDirty’ appears to run even on fully published and clean pages. Dirty pages do not execute this function; since the page is already dirty, why test again? So including this in the folder action will force something to execute before any page content is considered.

My previous testing in FW4 revealed that the publish precedence is folder > page > items. So this function would be executed mighty early in the publish cycle. (I posted a pdf outlining my findings.: http://www.coastalrugs.com/Actions/developerstuff.html - Order of Operations, I don’t know what, if anything has changed in FW5)

So, taking into account that we now have a function that will execute on clean pages, a parameter may need to be written to the action that actually enumerates the pages previously ‘seen’ by the action. So, when fwIsDirty is executed, it compares what it now sees to what it previously saw. From there you could either update the parameter or return true, both should accomplish the same task of re-dirtying all daughter pages.

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

3

Well, I could have this:

function fwIsDirty(){
    return true;
}

That will probably do the trick. This Action only runs on the last page in the folder/site, and it doesn’t do anything to the page, so that’s probably harmless unless the last page has a lot of heavy content applied to it.

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

4

But aren’t you marking the page as dirty before you decide if it’s the last page
in the directory? You’d ideally want to only mark the last page as dirty as
forcing the whole directory contents to republish just to create the var file
is a big overhead.
I’d like to see something in the API that allows us folk to do this sort of work
without having to jump through these ‘fwISDirty’ hoops.
Regards,
Tim.

Quoting waltd email@hidden:

Well, I could have this:

function fwIsDirty(){
    return true;
}

That will probably do the trick. This Action only runs on the last page in
the folder/site, and it doesn’t do anything to the page, so that’s probably
harmless unless the last page has a lot of heavy content applied to it.

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

–
Extend Freeway the way you want with FreewayActions.com
http://www.freewayactions.com

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

5

You’re right of course. If we could call fwIsDirty() directly, inside
another block, then this would be simple.

Walter

On Jul 22, 2008, at 7:57 PM, email@hidden wrote:

But aren’t you marking the page as dirty before you decide if it’s
the last page
in the directory? You’d ideally want to only mark the last page as
dirty as
forcing the whole directory contents to republish just to create
the var file
is a big overhead.
I’d like to see something in the API that allows us folk to do this
sort of work
without having to jump through these ‘fwISDirty’ hoops.
Regards,
Tim.

Quoting waltd email@hidden:

Well, I could have this:

function fwIsDirty(){
    return true;
}

That will probably do the trick. This Action only runs on the last
page in
the folder/site, and it doesn’t do anything to the page, so that’s
probably
harmless unless the last page has a lot of heavy content applied
to it.

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

–
Extend Freeway the way you want with FreewayActions.com
http://www.freewayactions.com

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

6

I just ran across this property:
fwStructureDirty

In a folder-action it would be:

if(fwItem.fwStructureDirty) .... a page has been aded or removed

a page-action it would be fwFolder.fwStructureDirty

Thus property appears to operate independent of dirty pages, even if all the pages within a folder are ‘clean’ and one of them is deleted (thus not causing any of the pages to dirty) this property still toggles to ‘true’. Additionally, it appears to only be ‘concerned’ with the cataloging of pages. It does not appear to be triggered if a page is dirtied via a content or design layout change, but is triggered when a page name or filename is changed. It seems tailored to exactly what was originally asked.

The only thing that does not seem to trigger it, is when the order of pages is changed, ie dragging pages up or down within the site palette.

Combine this property with the fwIsDirty (which we need to force some examination of the code even if all the pages are clean).

The following is the code I just used to test this inside a folder-action:

function fwIsDirty(){
	if(fwItem.fwStructureDirty) alert('dirty stuff');
}

function fwAfterEndHead(){
	alert('natural');
}

the ‘natural’ alert is there to differentiate between the method that is triggered. Clean pages will run fwIsDirty, and dirty pages will naturally run the fwAfterHead function.

The experiment: With a blank document create several pages with an attached folder action with the above code and publish. They will all popup ‘natural’ because the pages are following a normal publish routine. Delete one of the pages and republish. They will all pop up ‘dirty stuff’, although if you note, none of the pages actually needed publishing as they were all clean and would not otherwise be examined.

The following is a bit rambling although I thought it was applicable:

Don’t forget, the property ‘causeschange=“no”’.

I had not expected this to work with action-file’s, but appears to work as expected, not triggering dirty daughter pages.

Side note: The folder action knows that it is a folder action, so ‘fwItem’ refers to the folder to which the action is applied… fwItem.fwItems is the equivalent of the daughter pages. fwLastPage and similar work on this object.

As far as actually dirtying a specific page remotely, Paul had a similar quandary a while back and discovered his own solution:
http://www.freewaytalk.net/thread/view/717
(I am not sure how valid the action dirtying routine is at this point, since SP made some progress eliminating those gremlins, though they do persist sometimes)

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

7

I thought I remembered something in one of documents about dirty pages. Just in case you cant remember what or where it was and I don’t know if this is something that could be adapted to work with weavers fwStructure.

function fwDirty(){
// if the last page generated is not the same as the current page then we are dirty
var nextPage = fwFolder.fwNextPage(fwPage);
var currPage = fwParameteres["Last Page"].fwValue.fwInternal;
return nextPage != currPage;}

max

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

8

Thanks, guys. This gives me a lot to chew on here. I’ll try to add something from this and see if I can sort it out. Perhaps I can read in the existing Type Map (if it exists) and compare it to the generated one, and use that as my test for update.

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

9

This isn’t working at all for me in FW5. Have you tried it there lately?

Thanks,

Walter

On Jul 22, 2008, at 11:07 PM, Weaver wrote:

function fwIsDirty(){
	if(fwItem.fwStructureDirty) alert('dirty stuff');
}

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

10

In the end, I had to get out and push. In order to keep Freeway polling the folder for structure changes, I resorted to this wee hack:

function fwIsDirty(){
	fwItem.fwLastPage.fwSetDirty();
	return;
}

This forces the last page in the folder to be dirty on each publish, and thus the directory scan happens and the Type Map file is updated.

I tried all sorts of variations on the fwStructureDirty tune, and could not find anything that would fire reliably.

Thanks all for your help.

Walter

actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options