I have a number of related Devpack components that both use portal to add PHP code at the pageStart. They are dependant on their associated initialisation component.
It seems that the portal insertion code always adds at the page start regardless as to whether other portal pageStart code has already been inserted at the page start.
Ideally, the portal processing should insert the code in the order that it is requested on the page i.e. the first component to request it should insert right at the top and then the second component requesting should have its code inserted after the first one.
For the moment (and in this case) I can get round the problem by moving the first (initialisation) component after the second one.
I would like to be able to specify to a user using this DevPack that the initialisation component must be the first one on the page.
Are you saying that you have multiple separate components that rely on the presence of a “initialisation” component (and possibly each other)?
If so, we would like to remove any need for components having to rely on each other being on the page - (we don’t want to end up with any components on the page that are for “configuration” or setup code)
We actually have a way for developers to add initialisation / config / shared code. In your dev pack you can add the following shared file:
One thing to note is that pageStart and pageEnd are not currently supported in here, but I will discuss this with the team and see if it’s possible to get that added in the near future.
I think if the dev pack shared folder supported the pageStart, it might solve the issue you’re having, and hopefully remove the need for any type of initialisation/config components.
If you still think there would be a need for your initialisation component, please let me know the use case so I can better understand what you’re trying to achieve, and see if we can solve that in another way!
I have had a look at shared files but I would need to have page level user configurable properties which is why I am using an initialisation component. The user (web page designer) configures the Sitelok options when setting up the page.
The properties are used to setup the configuration for Sitelok and also to set user options so that when viewing in Preview the webpage can show either a logged in state or logged out state. The user needs to be able to flip this state easily amongst others. An example set of properties (work in progress):
I am aiming to make the setup of Sitelok as simple as possible and avoid the user having to copy and paste code into the Page Start section in the page settings.
There are other Sitelok components on the page: On or more Sitelok Control(s) and Sitelok Menu. Sitelok Control contains one or two drop zones: one for logged out and one for logged in. Sitelok Menu shows a different menu when logged in and logged out. Both of these need to know the logged in state to display correctly in Preview.
I hope I may have found a way round the Page Start ordering.
I want to find the best way to make this work with Elements.
An idea might be to have global properties (keyed by an id of some sort) that could be referenced in a component (a global properties section) that could be shared between components on a page. This means that the initialisation properties could be defined within the using components and changing a global property in one, would change it in the other. This would negate the need for an initialisation component?
Okay, I think for the time being continue doing what you’re doing to get things working. In a future beta we’ll add a way to handle this much better - we’re thinking something along the lines of if you add one of the page lock sub components, Elements would automatically add a “Site configuration” component for you.
