The backoffice UI has a tendency to not "remember" what node you've clicked on in the left hand tree display. This has lead to situations where I've accidentally put role-based restrictions onto the root content item when I meant to put it on a child node.
It also, just now, led to me deleting EVERY SINGLE ONE OF MY TEMPLATES.
I'm sure there's some kind of confirmation box that comes up before that happens.
But I'm equally sure that this is a really, really, really bad bug that needs to be quashed. Yesterday.
But it might be nice if the thing I'm deleting is actually the thing I clicked on. Sure, the text may be there (although I'm not sure all the confirmatory dialog boxes show the name of the object to be deleted), but it's a flaw in the user interface for operations to be applied to a node other than the one that has the visual cues of being selected associated with it.
Yes, you are right, this is a bug I have also fallen short of a few times, I think it is a browser issue rather than a specific issue with the xTree code. Which browser were you using? I think I remember this issue happening in Firefox. Usually when trying to delete multiple items quickly one after the other.
I hope you had all your templates stored in source control?!
Sorry about not replying sooner, I've been busy working on the site.
I've only used Firefox to access the backoffice, so, yes, that's where I was seeing the bug. It seems, as you said, to happen when I take actions too quickly one after another. In fact, my current workaround is <do something>, click the node again even if the <something> didn't change my position in the tree, and then do the next thing.
Maybe another workaround is to access the backoffice only through IE? I much prefer Firefox to IE...but I really detest trashing my entire site even more :). Which is what apparently happened to me, the only solution I could find was to erase everything and start over. Ouch!
Fortunately, my development version was pretty closely sync'd with the production version.
I would definitely suggest you get a source control solution setup asap! It saves a lot of headaches!
We store all our site source in SVN and although we might make small changes on our test sites (local machine) we always make the final changes in visual studio and then do a build which copies these files over the top of the current test site. You learn pretty quickly to remember to copy your changes into Visual Studio before doing a build!
Once you have got into a good habit if seeing the files in VS as your primary files, you'll never accidently delete all your files again :) And if you do, all you need to do is a re-build of your project and everything is back :)
We have our SVN server setup to automatically copy the same files onto a shared development server on every check in, so we can immediately test the site with everyone's changes. You quickly find the macro's you've forgot to duplicate or the missing parameters on the doc types. The means copy to stage and finally live should be a relately pain free experience.
Terrible, Horrible, Bug!
The backoffice UI has a tendency to not "remember" what node you've clicked on in the left hand tree display. This has lead to situations where I've accidentally put role-based restrictions onto the root content item when I meant to put it on a child node.
It also, just now, led to me deleting EVERY SINGLE ONE OF MY TEMPLATES.
I'm sure there's some kind of confirmation box that comes up before that happens.
But I'm equally sure that this is a really, really, really bad bug that needs to be quashed. Yesterday.
- Mark
Yes there is a confirmation box that appears on most context menu actions. If you agree to it then how can you be stopped?
Also, 4.1 will bring an entirely new tree which isn't xTree and works 1000 times better
But it might be nice if the thing I'm deleting is actually the thing I clicked on. Sure, the text may be there (although I'm not sure all the confirmatory dialog boxes show the name of the object to be deleted), but it's a flaw in the user interface for operations to be applied to a node other than the one that has the visual cues of being selected associated with it.
- Mark
Hi Mark,
Yes, you are right, this is a bug I have also fallen short of a few times, I think it is a browser issue rather than a specific issue with the xTree code. Which browser were you using? I think I remember this issue happening in Firefox. Usually when trying to delete multiple items quickly one after the other.
I hope you had all your templates stored in source control?!
Cheers,
Chris
I can confirm this behavior happens in Firefox. Is there a known fix for this?
I'm going to be looking into this for one of our clients this week.
/L
Chris,
Sorry about not replying sooner, I've been busy working on the site.
I've only used Firefox to access the backoffice, so, yes, that's where I was seeing the bug. It seems, as you said, to happen when I take actions too quickly one after another. In fact, my current workaround is <do something>, click the node again even if the <something> didn't change my position in the tree, and then do the next thing.
Maybe another workaround is to access the backoffice only through IE? I much prefer Firefox to IE...but I really detest trashing my entire site even more :). Which is what apparently happened to me, the only solution I could find was to erase everything and start over. Ouch!
Fortunately, my development version was pretty closely sync'd with the production version.
- Mark
Hi Mark,
I would definitely suggest you get a source control solution setup asap! It saves a lot of headaches!
We store all our site source in SVN and although we might make small changes on our test sites (local machine) we always make the final changes in visual studio and then do a build which copies these files over the top of the current test site. You learn pretty quickly to remember to copy your changes into Visual Studio before doing a build!
Once you have got into a good habit if seeing the files in VS as your primary files, you'll never accidently delete all your files again :) And if you do, all you need to do is a re-build of your project and everything is back :)
We have our SVN server setup to automatically copy the same files onto a shared development server on every check in, so we can immediately test the site with everyone's changes. You quickly find the macro's you've forgot to duplicate or the missing parameters on the doc types. The means copy to stage and finally live should be a relately pain free experience.
Cheers,
Chris
is working on a reply...