Support/Comments for Provisioner 1.9-beta

This is an auto-generated topic for Provisioner 1.9-beta by shamblett.

Brief Description:

This package allows provisioning of a Revolution site from either a remote Revolution or Evolution site. Resources, elements, files, packages and user information can be viewed/imported. Please read the user guide in /assets/components/provisioner/docs for exact usage details. Also remember to install the revogateway connectors pack into any Evolution site you wish to use. See the changelog for details of fixes in this version. The source for this package is now in GitHub at http://github.com/shamblett/provisoner
Evolution site import now much improved, allows variable time for import sequence, imported resources keep their Evolution id's, the import is logged to a text file to aid debugging. Other fixes across the package as a whole.

Hey Steve,

Great work on the Provisioner component so far!

This is the first time I’m trying to use Provisioner for migrating stuff between two Revo sites. Unfortunately, I’m having troubles logging into the remote Revo site. When I attempt to login from the Administration tab, I get the following error:

"Login to the Remote Site failed - Connector URL not found"

Granted, if this was an Evo site, the error would be an obvious fix. Any idea what the problem is?

Jeff

For the Revo sites you need the connector URL, not the site URL, so you need for instance ’www.mine.revolution/connectors’, not just ’www.mine.revolution’ as you do with Evo. This is because you can move the connectors directory on install in Revo so Provisioner needs to know where it is. You also need the remote Revo site’s API key but you probably know this.

Thanks Steve! Yeah, I figured that out right when you posted a reply. Seems to work now.

So far, so good. Only one thing that could use improvement (and I’m sure you already know this). Really need to have it so that when you import a resource (page) its corresponding template variable values get imported in as well. Granted, this is tough...but if you can crack this egg it’ll make this component 10 times more useful. The main thing I’m using this for right now is for migrating changes for various resources, templates and chunks from a dev environment to a live production site. Only thing that is slowing me down is the lack of template variable values for migrated documents.

There’s a ticket raised for this sort of thing(maybe even this in fact) in github. This can be done it’s more a matter of the GUI, some people might not want this, so it shouldn’t be default behaviour.

OK so we can add a menu entry for it, something like ’import with associated data’, the associated data being whatever is associated with what’s selected, so for a resource say you get the TV’s and templates, do we at this point also get the categories the templates/TV’s belong to? Do we get document groups, user groups and hence by default users, access policies etc? We could add more specific menu entries, this however would create confusion and clutter IMHO.

Another option is to have a mode setting that applies across the board, if the mode is set to ’associate’ say this becomes the default action, so import will automatically do all this, nice and clean, just one menu entry like now.

Associated data importation tends to sprawl, your mileage may vary on what you think should be imported, it’s difficult to get this right for all users.

Indeed, definitely a tricky thing. From a UI point of view, maybe one of the ways you could do it is to simply add a little array of checkboxes just below or to the side of the resource tree. The checkboxes would allow you to check off what associated data you would like to import (ie. TV values, document groups, user groups, etc.). Keep it simple.

Starting off, I think at least allowing the import of associated template variable values would be of the most use. The other stuff could be rolled in once you figure out the logistics and UI challenges. For now though a simple checkbox that says "Import associated TV values" would work.

Just a few thoughts and ideas for ya!

Hi,

I tried 1.9 beta this morning, going so far as to download NeOffice so I can view the .odt doc with instructions.

It "seems" to work but it didn’t. The login worked but it didn’t write anything into the web context. So I selected the provisioner context and nothing gotten written over there.

Also, the gateway app is installed on the Evo install... made me wonder: is Provision just for a single domain?

The log is here:


I renamed the domain above to protect the client.

Peter

Hi, there are a number of things to check depending on what you are seeing, you logged in OK without error to an evo site presumably, did you the see the resources from that site in the tree on the resources tab? Was it an import that failed? The cookie file looks OK, your right about the docs, the next release will hav a PDF version.

It was the import that failed. I could see everything in the Evo site from within the Revo site (very cool by the way).

The bottom of my browser displayed a status that looked like this:


When the failed import was done, that displayed "Done" instead of the manager URL. Just another clue.

Also, does it matter that the domains that I’m using are all on our dedicated server?

I’m actually going to set up another subdomain, do a fresh install of Revo, installed Revogateway into another Evo site (I have about 15 to convert and starting to wonder if the 6 of mine should be set up as contexts in Revo, but alas I’m just too conservative).

UPDATE:
It worked on a fresh Revo site. It failed on the site that had the Demo site "modxss" installed.

What I did different from the failed import:
1) Installed Revo (installed Revogateway on the Evo site, but that’s not different)
2) Installed Provisioner via Revo’s Package Management
3) Logged into the Evo site via Provisioner
4) Imported the site with Snippets and Chunks selected.
4a) Still need to SFTP the template files over. Just so you know, I don’t expect that as a feature of Provisioner.

My question then is: why did Provisioner fail to import into the default web context that was populated? The warning says that the import is going to overwrite anything and everything selected to import.

Nice work! Thank you for your efforts on this. I’ve now gotta hold my own hand and try creating a new context and see if Provisioner will import a different Evo site into that.