Hi! Our college is looking into using Macromedia Contribute to manage content. I would like to have contribute manage content stored in zope. Unfortunately, Contribute uses a '_mm' folder to store isn't site configuration information. Since this is a protected id, when Contribute tries to setup an ftp connection and create this folder it fails. Is there any way I can either allow _mm to be created as a folder, or is there some other way around this? I've thought about trying some sort of pre_traversal hook that would translate _mm to mm_ (or some valid id) when it's requested, but I don't know how to do that. Actually, I don't know if 'pre traversal hook' is even the right term; because is it really 'traversal' when you are requesting an 'mkdir _mm' via ftp? Any help would be VERY GREATLY appreciated! Thanks, Andy
Andrew Altepeter wrote:
Our college is looking into using Macromedia Contribute to manage content. I would like to have contribute manage content stored in zope.
Unfortunately, Contribute uses a '_mm' folder to store isn't site configuration information. Since this is a protected id, when Contribute tries to setup an ftp connection and create this folder it fails.
Whatcha-call-it... Frontpage suffers from this same malady. You should see what solutions have been suggested for that.
Is there any way I can either allow _mm to be created as a folder, or is there some other way around this?
I've thought about trying some sort of pre_traversal hook that would translate _mm to mm_ (or some valid id) when it's requested, but I don't know how to do that.
That is a good solution to the problem in general. If you're only interested in FTP, it has special methods that you might over-ride for the same effect. If may be possible to do a slightly easier fix with a product that does rewriting at the Zope level. I know there exist (though I never did get them to work) products called Rewriter and Redirector. Their "forwarding" may not care about object name rules.
Actually, I don't know if 'pre traversal hook' is even the right term; because is it really 'traversal' when you are requesting an 'mkdir _mm' via ftp?
Yes. Traversal happens anytime an object is published, even if it's not through HTTP. --jcc -- "He who fights with monsters should look to it that he himself does not become a monster. And when you gaze long into an abyss the abyss also gazes into you."
J Cameron Cooper wrote:
Yes. Traversal happens anytime an object is published, even if it's not through HTTP.
You could try a Site Access Rule in the root folder... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi Chris and JCC, Thank you both for your help! In order to get this '_mm' folder working, I had to do a couple things: 1) Add a site access rule in the root folder, that replaced any '_mm' items in the TraversalRequestNameStack with 'mm_' 2) in OFS.Folder.manage_addFolder, add an if statement that maps _mm to mm_ 3) changed OFS.ObjectManager.objectItems to: def objectItems(self, spec=None): return [ ((id=='mm_' and '_mm' or id), self._getOb(id)) for id in\ self.objectIds(spec) ] This allowed me to access '_mm' as a folder, through ZMI, normal published object, and ftp. I do believe there are a couple more places in ObjectManager that need to map _mm to mm_. One I can think of is _delObject Even though I got this piece working, I was still unable to get Macromedia Contribute to function. It wouldn't even let me connect via ftp to zope. Well, it would connect, but then it would tell me that access was denied. Checking the access logs, it looks like everything it was trying was successful (except for doing a chmod on a temporary file it created). Overall, I'm not very impressed with the site setup wizard in Contribute. Thanks again for all you're help, Andy On Mon, 2004-03-22 at 10:19, Chris Withers wrote:
J Cameron Cooper wrote:
Yes. Traversal happens anytime an object is published, even if it's not through HTTP.
You could try a Site Access Rule in the root folder...
cheers,
Chris
Andrew Altepeter wrote:
1) Add a site access rule in the root folder, that replaced any '_mm' items in the TraversalRequestNameStack with 'mm_'
How're you preventing your users from adding objects called 'mm_'? ;-)
2) in OFS.Folder.manage_addFolder, add an if statement that maps _mm to mm_
Should probably do that in a subclass :-/
3) changed OFS.ObjectManager.objectItems to: def objectItems(self, spec=None): return [ ((id=='mm_' and '_mm' or id), self._getOb(id)) for id in\ self.objectIds(spec) ]
This allowed me to access '_mm' as a folder, through ZMI, normal published object, and ftp. I do believe there are a couple more places in ObjectManager that need to map _mm to mm_. One I can think of is _delObject
Yeah, sounds like a lot of pain and suffering :-S
Even though I got this piece working, I was still unable to get Macromedia Contribute to function. It wouldn't even let me connect via ftp to zope. Well, it would connect, but then it would tell me that access was denied. Checking the access logs, it looks like everything it was trying was successful (except for doing a chmod on a temporary file it created).
So what was failing then? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Thu, 2004-03-25 at 03:38, Chris Withers wrote:
Andrew Altepeter wrote:
1) Add a site access rule in the root folder, that replaced any '_mm' items in the TraversalRequestNameStack with 'mm_'
How're you preventing your users from adding objects called 'mm_'? ;-)
I have to say, I'm not too concerned about that. But if they do, then it's also accessible via '_mm' ;-)
2) in OFS.Folder.manage_addFolder, add an if statement that maps _mm to mm_
Should probably do that in a subclass :-/
That's a good suggestion. If I ever need to provide this sort of support on a production box in the future, I'll try doing it that way.
Even though I got this piece working, I was still unable to get Macromedia Contribute to function. It wouldn't even let me connect via ftp to zope. Well, it would connect, but then it would tell me that access was denied. Checking the access logs, it looks like everything it was trying was successful (except for doing a chmod on a temporary file it created).
So what was failing then?
Without seeing the source code for Contribute, I can't really say. Everything appeared to be successful, but then it gave a magical 'Access Denied' or 'Unable to Connect' error message. I do think it was looking for a _mm/contribute.xml (a contribute sites configuration file) in the zope root. If I did that, it would *work*. However, that meant I was unable to setup other contribute sites in zope. I actually copied that config file from a site served directly from apache into zope. The odd thing is that once or twice I was actually able to connect and go through more of the wizard to setup a site (w/out using that contribute.xml file). Every other time it failed, and not always in the same spot, or with the same error message. I wanted to save the pages contribute created as zpt's (which works). Unfortunately, It created the files like: --- <doctype ...> <html> ... --- And the zpt parser apparrently doesn't like that empty line between the doctype and the <html>. Cheers, Andy
cheers,
Chris
Andy Altepeter wrote:
Without seeing the source code for Contribute, I can't really say. Everything appeared to be successful, but then it gave a magical 'Access Denied' or 'Unable to Connect' error message.
Hurm :-/ You could always run up something like Ethereal or TCPWatch and actually look at the packets, they may give you a clue...
I wanted to save the pages contribute created as zpt's (which works). Unfortunately, It created the files like:
--- <doctype ...>
<html> ... ---
And the zpt parser apparrently doesn't like that empty line between the doctype and the <html>.
It may well violate the HTML spec then :-/ cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Mon, 2004-03-29 at 09:16, Chris Withers wrote:
Andy Altepeter wrote:
Without seeing the source code for Contribute, I can't really say. Everything appeared to be successful, but then it gave a magical 'Access Denied' or 'Unable to Connect' error message.
Hurm :-/
You could always run up something like Ethereal or TCPWatch and actually look at the packets, they may give you a clue...
I don't think that would help, though. I think it's a problem within Contribute. I've read on a macromedia forum that other users were having difficulty with contribute and ftp... Andy
Andy Altepeter wrote:
I don't think that would help, though.
Don't say that until you've tried it ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (4)
-
Andrew Altepeter -
Andy Altepeter -
Chris Withers -
J Cameron Cooper