Jump to content

Move users to own auto-increment page id?


netcarver
 Share

Recommended Posts

I'm working with a client that uses PW to provide the basis for various services, and GDPR/legalities mean that the data for our EU-based users has to live on an EU-resident server. Similarly, US-sourced data has to live on US-resident servers. As the sign-up rates are different in each region, the page IDs between the sites quickly get out of sync, so when new features involving pages are added to the US and EU sites, the IDs of the pages housing new options/blog posts etc are out of sync between them - making references to the pages in the code-base using the page ids impossible.

The only thing causing the desynchronisation between the installs is the user pages.

I know we can use different programmatic techniques to reference these feature/structural pages, but I'm curious; is it possible to force users (any page using the user template - or any alternative user template) to use a separate auto-incrementing id in PW?  I don't think so, but if it could be done, how would you approach this?

Being able to have fixed ids for landmark pages, despite differing sign up rates across regions, would be handy.
 

  • Like 2
Link to comment
Share on other sites

  • netcarver changed the title to Move users to own auto-increment page id?

Probably not an optimal solution, but maybe you could create a 'dummy' user on the 'other' server at the time a genuine new user is created? Then there's a chance both servers will match, although race conditions etc...

  • Like 1
Link to comment
Share on other sites

19 hours ago, netcarver said:

is it possible to force users (any page using the user template - or any alternative user template) to use a separate auto-incrementing id in PW?

Pages::___save() method has a forceID parameter:

	 * - `forceID` (integer): Use this ID instead of an auto-assigned one (new page) or current ID (existing page).

I've never tried to do anything like this, but it seems like this would be a good place to start, e.g. hooking before this method and forcing the ID in case of a new page using the user template. You would still have to figure out some way to share auto-increment ID values between instances ?

  • Like 2
Link to comment
Share on other sites

@teppo, that might work if we combine it with an idea from @adrian. If we set a high initial value for ids (say 1 million) and allow pages using the user template(s) to use these independent autoincrement IDs at whatever rate the users sign-up at. We could try using our own, sub-1,000,000 counter value when adding pages with any other template. There won't be that many of them and we going to share these pages amongst all the installations anyway.

Link to comment
Share on other sites

Why not use a custom page name as a reference/ID across those instances?

You could create those "on the fly" when someone is signing-up and therefore that "ID" would be unique.

us-[timestamp]-{page->name}
eu-[timestamp]-{page->name}

Sure... using Page IDs is way easier, yet creating your "own ID" or using a "foreign key" could be an option.
Needed this within a product catalogue (not users) but still. It worked out quite well.

  • Like 1
Link to comment
Share on other sites

One more possibility: get your non-user pages by path instead of by ID. If you use PagesLoader::getByPath() it should be just as robust as getting by ID because page path history will handle any renaming or moving of pages. And as a bonus the code is more readable because it's more obvious what page is retrieved by '/about-us/sustainability/' than by 24875.

$p = $pages->loader()->getByPath('/about-us/sustainability/', ['useHistory' => true]));

 

  • Like 3
Link to comment
Share on other sites

Maybe I'm off base here, but since you say the user is the issue, why not create your own ISAM routine by hooking the registration to it's own domain/database and passing the result to the proper installation login/user.

  • Like 2
Link to comment
Share on other sites

Late to the party but I agree with the approach by @rick. This is a database layer issue and I would approach it with a database solution, in the first instance, instead of a code one (hooks, forcing IDs, etc).  Given, the forceID flag was added for a reason but for an operation of the scale and intricacy you are dealing with, I'd let the database handle IDs. The 1M idea is clever but given that you are enforcing it through code, it takes one or two mistakes/glitches and you could end up with some 'lost' users (e.g. with IDs < 1m). 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...