125 replies to this topic

[ryan]

The "noMove" option means that the page can't have it's parent changed. But it may still be sortable with it's siblings.

The PageList uses the "move" label in a more general sense to refer to either changing the parent, sorting, or both (just depending on where you happen to drag the page to).

As a result, a "move" link may still appear in the page list even if a page's template has the "noMove" option set. In this case, the "move" link is only referring to sorting within the same parent.

If you drag the page to another parent, PW should tell you "no". Though, after getting the alert box, it might still look like it moved in the PageList, but that's only because I haven't figured out how to reverse it from the javascript (yet). The page didn't actually move. Hit reload or click "pages" and it'll be back where it was. Though let me know if you find it's not working this way. 

[Oliver]

Yeah, I’m currently reducing functionality for a first test version.

Just a general question: If page trees are synced, what page attributes/properties would you guys like to be synced? Parent, order, template, status? Anything else? Or anything definitely not?

[Pete]

If you're syncing a page so that one you've created in one language is then copied to another I would say that it's status should be unpublished by default - I'd personally want to finish translating a page in that case before I publish it.

Something that could be useful even in a version 1 would be the option to exclude copying pages with a certain template. One site I'm working on will have everything translated to different languages as the company does work in a few different places in Europe, but the news won't be relevant in different areas so I wouldn't want to sync news articles in that case. I imagine, though I obviously can't think of every scenario, that this would be a very useful feature. The only problem I can see is if you accidentally exclude a template for a page with children using a different template - what happens then? Does it just not copy the children or could it run the risk of not working at all and throwing an error? So... maybe this idea is not as simple as it first sounded

[Soma]

Yeah, I’m currently reducing functionality for a first test version.

Just a general question: If page trees are synced, what page attributes/properties would you guys like to be synced? Parent, order, template, status? Anything else? Or anything definitely not?

Hard to say really. Parent, order, status as you said I think for sure. But now I'm thinking about custom fields that's used for additional statuses, I'm thinking of the ones I need to create for each template because core doesn't have it the way I need it, like "not_in_navigation" checkbox and "not_searchable"... So if possible, there should be a way to add custom fields that needs to be synced on a template basis.

I think it will be easier to find out once a first alpha can be tested.

[Oliver]

Pete, you reached the point of the story, that has been driving me nearly crazy for over a week now.

As soon as you exclude pages, there has to be a logical way to deal
a) with its children, as they were synced
b) with synced pages maybe moved below the unsynced page as its children

Soma, that's a good point. But a complex one, I guess. Maybe a cool feature for version 2 or 3.

[ryan]

Not sure if this all applicable, but I'll mention it because I think it gets into the two issues you mentioned. You may already be doing something like this. But I'll type it out just in case any of it is worthwhile.

I do some cross-site syncing where pages from one PW site are duplicated on other PW sites and then mirrored every hour. The sites have different structures, so the mirrored pages have to remember where they came from. This is accomplished by maintaining a 'master_id' (integer) field on every page. That field contains the ID of the page at the originating site. So even if the page is moved in the structure, it continues to be mirrored since it's master_id will never change. If I want a given page to stop mirroring, then I just set it's master_id to 0.

Perhaps in your case, keeping a master_id field containing the ID of the page it was duplicated from would ensure that it could continue to be synced regardless of where it gets moved to in the future. Since synced pages would be sharing the same template as the master, they would both have a master_id field. So one way to differentiate the master from the others would be to use a signed ID… they both have the same number, but the master has a positive and the other(s) have negative number (master_id * -1). Canceling the mirroring at either end would just mean setting it to 0.

Any templates you want to mirror you would add a master_id field to in Setup > Templates. Your $pages->save() hook would monitor pages that have this field and populate it when creating a page. Likewise, they would create the corresponding page(s) (with the negative master_id) as child(ren) of any other pages that had a master_id equal to the saved page's parent_id * -1.

If you didn't want the parent to be mirroring, but you wanted its children to mirror, then the master parent would have a master_id of 0, and the other corresponding parents would have a master_id of the master parent's ID * -1. I think that the default would be that any page created that has a master_id field in it's template would be assumed to be mirrored until you set it to 0.

I may not understand the full scope of your needs, so correct me if I'm wrong… but wouldn't this sort of approach be a simple solution to the two issues you mentioned?

[Pete]

@ryan - slightly off-topic here, but can you roughly describe the scenario where you need to sync pages across multiple sites? I'm also intrigued as to how that would be acccomplished.

[Oliver]

Thanks for the input, Ryan.

Currently on installation the module creates a first language tree (english) automatically. It can be renamed to whatever language you want it to be. It is set as default language, because there always has to be one defined. The default language is the one you are redirected to when you access the root page as a visitor. Also it’s the master for all languages with sync set to 1.

I reduced the functionality for this first version to the pure syncing of the language trees to all actions performed on (mapped) pages in the default language tree, syncing templates, sort, status, parent.

I guess, in case of translations it makes more sense to keep the page hierarchy synchronous–and implement pages not synchronized by an option to exclude them from standard sync behaviour.

[Soma]

Just thinking. How would we handle images then? upload again on each page?

[ryan]

PW's page cloning supports images/files too. I suppose it just depends when the cloning takes place as to whether the images are duplicated there. You never really know if an image is going to need to be language specific or not, though it's description (alt tag) would be. I tend to think it's best to follow a path of more duplication here rather than trying to squeeze out some efficiency benefits in less duplication. Either way, any kind of image or file mirroring would seem more like a luxury than a requirement, in my opinion. If I were building a multi-language site, I would probably keep some pages for shared assets (outside of the language trees) and pull shared images from there when necessary. I'd reserve the on-page image and file fields for language specific stuff, not to be cloned across trees.

@Pete: Technically it's not different than any other web service for sharing content, except that it's a little more custom and deals with larger sets of data. This particular one is specific to a company intranet, so there aren't public examples I can link to. I won't get into the unique parts since it's not my own site, but can describe the general ideas common to most web services of this kind. The master server has a REST-based web service, which I just built with a template and assigned it to a page. That web service lets you query PW with selectors and it responds with JSON results containing all page data. The other web servers query the web service from a cron job calling PW's API from PHP command line scripts. They look for pages that have changed since the last query, and re-populate all the page's fields with the data parsed from the JSON. It mirrors all fieldtypes including files and page references, as well as child pages. It determines if something has been deleted by it's lack of presence in the JSON feed. If there's a page on one of the servers with a master_id that no longer appears in the feed, it moves the page to the trash and ultimately deletes it. This system deals with tens of thousands of pages, so it doesn't all happen in one request. Let me know if I can answer any more specific questions about it. Though maybe we should switch to another topic so we don't hijack this thread.

[Soma]

PW's page cloning supports images/files too. I suppose it just depends when the cloning takes place as to whether the images are duplicated there. You never really know if an image is going to need to be language specific or not, though it's description (alt tag) would be. I tend to think it's best to follow a path of more duplication here rather than trying to squeeze out some efficiency benefits in less duplication. Either way, any kind of image or file mirroring would seem more like a luxury than a requirement, in my opinion. If I were building a multi-language site, I would probably keep some pages for shared assets (outside of the language trees) and pull shared images from there when necessary. I'd reserve the on-page image and file fields for language specific stuff, not to be cloned across trees.

But when sharing the files through a resource page, it would then only be possible to inserting them in tinymce, not for image fields on page?
So what if I like to have an image field allowing 1 image, to be able to be on a predefined place on the layout, and which is not language specific?

[ryan]

Actually, I wasn't even thinking of TinyMCE, but you are right that would be an option. What I was thinking of was a shared assets page, and I use them on a lot of sites already. Language-specific pages could pull from those shared assets like any other page, i.e.

<?php

$masthead = $pages->get("/tools/shared/masthead/")->images->getRandom(1); 

$alt = array(
    'en' => 'Masthead',
    'de' => 'Impressum'
    ); 

$lang = $page->rootParent->name; 

echo "<img src='{$masthead->url}' alt='$alt[$lang]' />";

[Soma]

Thanks for the offer, Soma. Would help, if you tell about the functionalities you’d expect such a module to have. Maybe it gives me an hint for the one or other question I still have to get an answer for.

The real complex thing still is to keep the page mapping (associating the different language's translations of a page with each other) consistent, while allowing pages to be moved, trashed or deleted and also to providing the possibility to have pages in a language tree that aren’t sync’ed with other languages.

I implemented a sync option to automatically sync a language with the defined default language. So creation and deletion of pages in default language’s page tree will be repoduced within the synced language’s page tree all the way.

Alternatively, you can deal with the translations manually by creating them from the language tab in the page edit form (as already said: by cloning as well as by creating an empty new page).

What would you guys suggest should happen, when a page is moved outside the language’s page tree or is trashed? On sync, I guess, the associated pages have to be deleted or–in case of being trashed–also be trashed.

I think it should also be trashed. That's just the most common.
But thinking about it, what would be if: "I only want to remove this mapped page from this lang tree AND not on other language tree". It would require to delete all and recreate all the others... not good. So it should at least be possible to "flag" if this page is mapped or not.

When a mapped page is moved within the language tree, the associated translations will be moved to the parent within their particular page tree, that is mapped to the new parent of the current languages page tree. But if you can have pages without a translation in the other language trees, what should happen on a page being moved to such unmapped page as new parent? Should this parent be replicated to the other language trees as new parent for the as well moved translations? Or should it be forbidden to move to unmapped parents?

I think it should be forbidden to move synced page to unmapped ones as parent. If parent is unmapped, all childs must be.

Maybe I just should reduce the functionalities to syncing the page trees 1:1 first.

Btw: What information on the current language is needed within the template? ISO-Code? LCID? Or what else? Let me know.

You mean a "$lang" var for use in templates,  I think ISO-codes 2 digit be the way to go...

[Oliver]

Thanks for the input! Sorry for keeping you waiting. Have a lot going on here at the moment, so I don’t get a real chance to work on the module again. Maybe more this week.

[Oliver]

After having lost focus on my sweet little module here, I’m back on it now. Stripping stuff to get it finally working including the most important functionality. And I start with a question again!

$this->hooks['unpagemapPageOnDelete'] = $this->pages->addHookAfter("delete", $this, 'unpagemapPage');

The hook above is triggered when a page is deleted (not trashed, really deleted). But I’ve to deal with two different situations: The trash is emptied, so every page in it is deleted. As by moving a language page to trash its translations go there, too, I don’t need to care for them being deleted and unmapped.
But as soon as I open the edit page of a page in trash and delete it by using the "delete" tab, the page is deleted and I actually have to care for its translations. So I need something to check on and choose a way how to process the unmapping. I guess the best way is to check the process. Can I access the process’ name in the function hooked to the event above somehow like this?

    public function unpagemapPage($event) {
        $page = $event->argument[0];
        if($page->process != "ProcessPageTrash") { 
        …

Thanks in advance, again!

[Soma]

hey lorgg

great to hear you're working on it again.

I think there's no reason to go delete a page manually in the trash? Just empty trash... ?

[Oliver]

Of course there is no reason. But there is the possibility to do it. And so I’ve to deal with the case someone uses the delete tab of the page edit form of a trashed page. Just to be sure the consistency of the page map won’t be corrupted.

[Soma]

BTW. Not sure if we already mentioned this. Will it be possible to have pages not being mapped?

[Oliver]

The first version won’t provide a possibility to exclude pages or parts of the language page trees from syncing. There already are methods and stuff included to implement it. I’ll also prepared the db tabels for it So it’s pretty sure, I’ll get it done for a later release.

There are several logical problems to be handled when unsynced pages are moved within a language’s page tree or synced once are moved into unsynced ones. I guess I can focus on it more clearly as soon as I got a basically functional version out and in use.

[ryan]

Glad to hear you are working on this one again!

if($page->process != "ProcessPageTrash") {

The only page that will have that process is the actual Trash page. I think you are trying to detect this instead? (the current process being executed?)

if($this->process != 'ProcessPageTrash') {

However, I'm not totally sure that identifying whether the current Process is "ProcessPageTrash" is useful to you? It sounds like you are trying to detect someone manually deleting a page in the trash. I'm wondering if you might want to use $page->isTrash() instead? You can call isTrash() on any Page object, and it'll return true if the page is in the trash.

I think there's no reason to go delete a page manually in the trash? Just empty trash... ?

I agree with Soma that it may be accounting for something I wouldn't expect to be accounted for. If something is in the trash, I suppose I'd assume that it's not still being managed by any other systems. However, you are right that it is possible for someone to go and permanently delete a page in the trash without emptying the trash, so if it's a situation you think needs to be accounted for, I'm sure we can figure out how. I'm thinking that isTrash() may be what you were looking for, but let me know if not...