Hi Dragan,
I assume you are using the "Basic Workflows".
Unfortunately, they don't support the "validity period" mechanism - which is quite rarely used by the way and thus even relatively unknown. I guess that might be one reason why it was not implemented in the Basic Workflows... Another reason might be that you would have to find an "usable" way for the editor who approves the release to also check the "alternate" page, especially in ContentCreator.
If you use the "manual" admin release together with "new and changed" this should work (will release both Page objects) - but then you would not be using the Basic Workflows anymore (at least in that special case) - especially the check for invalid outgoing references. This means you'd get no warning if (for example) the "later" page's content contains a link to a never released PageRef.
Some options that come to my mind are::
1. Accept it as a special case which is handled manually
If you are using the validity period mechanism only at very few places and can accept the "manual" (=admin release in SA) way: Go for it. Maybe you should nevertheless add another activity to the workflow that at least shows a warning in such cases when the PageRef has a validity period set.
2. Adapt the Basic Workflows yourself - GitHub - e-Spirit/basicworkflows: Basic Workflows for FirstSpirit (and do a pull request ;-))
If you are not familiar with the sources, this might be not that easy because they are quite "general". You'd also have to think about up a (usability) concept how you would let the approving editor really see the alternate page(s) - or at least give him a hint that they exist.
3. Modify the PageRef according to the validity period
You could also try to implement a script / schedule etc. that changes the PageRef in a way to point to the "new" Page when the validity period is reached. In that case, you'd use the validity period just as a kind of "information storage". Background: a PageRef's .getPage() method always returns the "default" Page (=the normally referenced one as if not using the validity period at all), even when according to the validity period it (currently!) uses another one (=the one in the validity period entry). That's by the way the technical reason why the Basic Workflows implementation do not support valitity periods: They rely on the PageRef.getPage() method to decide which elements to check and release.
You can also think about "mixing" some of those options' aspects - e.g. adapt the Basic Workflows to just use "new and changed" dependency - but you would nevertheless lose the validity check for the "alternate" pages, not sure if that approach would really work.
Regards,
Michael
