|
From: Johannes R. <rag...@ad...> - 2014-09-25 04:17:50
|
I also run into this problem today and factored out gotcha's code regarding https://dev.plone.org/ticket/13793 from https://github.com/plone/Products.CMFPlone/tree/publication-through-explicit-acquisition into a seperate package: https://github.com/collective/collective.explicitacquisition That's exactly his implementation as a separate package. Easy and unobtrusive to include, and got no problems with it so far. Mauro, which problems with image scaling did you have? I didn't encouter problems until now... Cheers, Johannes On Thu, 2014-08-21 at 08:59 -0500, Nathan Van Gheem wrote: > Wow, that'd be great if you looked into this! > > > Does anyone know what happened to the zope4 branch work way back when > before politics got involved(maybe I'm off base)? I'm not sure all > that this branch did but I think it at least gave us a webob based > request object. > > > IMO, I'd like to see plone on pyramid or a forked zope2 that strips > out a lot of the magic and is for plone specifically(maybe). *ducks* > > > On Thu, Aug 21, 2014 at 4:09 AM, Mauro Amico <mau...@gm...> > wrote: > > On Wed, Aug 20, 2014 at 10:06 AM, Dylan Jay > <dj...@pr...> wrote: > The fix mentioned by Steven is simpler than changing > traversal and seems reasonable to me. > Basically if you are going to publish something that > has an acquisition url, then raise a 404 instead. > > https://github.com/plone/Products.CMFPlone/commit/e20ea907d2854ee7ad41e9953b64889ee7431b49 > > > > Looks good for me. > > But looking more depth I see that comparing pysicalpath and > parents could be not ever so easy, at least I found that > traverse for image scaling doesn't work as expected: > > > http://localhost:8080/Plone/foo/@@images/da05bfd9-0fca-4c5f-b02d-f981b47a0788.jpeg > > > > request['PARENTS'] > > [<plone.namedfile.scaling.ImageScale object at 0xafd3292c>, > <Products.Five.metaclass.ImageScaling object at 0xafd32aec>, > <Image at /Plone/foo>, <PloneSite at /Plone>, <Application at > >] > > I don't know if the problem is only for some or all custom > traverser, and if it could be solved skipping not contentish > items from parents. > > > I agree with Martin and Nathan that "hacking" traversal could > be risky and for sure I trust your experience, but I think > that is a really annoying problem for many people using Plone > at this moment. For sure it is for me... > > > I'm thinking to create an experimental package, probably > starting from Godefroid code, so people can starts to testing > it also before "publication-through-explicit-acquisition" > merge. > > IMHO a full rewriting of publisher could be for next major > Plone release (6 ?). I'm happy to help for that, if needed. > > > Mauro. > > > > > > > On 20 Aug 2014, at 2:52 pm, Martin Aspeli > <opt...@gm...> wrote: > > > I once had a burning desire to clean up the mess > that is the publisher. I spend a long time trying to > just document what it does and how it works. The > results are here: > > > > http://docs.zope.org/zope_secrets/ > > > > I suggest you sit down. > > > > I don't think it's possible to make it much better > without braking some backward compatibility. There are > a million old hooks used in one or two places that > just need to go. > > > > If we are to clean it up, I'd look at repoze.zope2 > as a starting point. That code is much better and much > better tested, although now slightly out of date. > > > > Martin > > — > > Sent from Mailbox > > > > > > On Wed, Aug 20, 2014 at 12:55 AM, Nathan Van Gheem > <na...@va...> wrote: > > > > Okay, I'll take a short crack on this with some > thoughts. > > > > - The traversal side affects shouldn't matter unless > you're directly linking to them? How come your links > are getting messed up? > > - Changing zope2 traversal will likely have a lot of > side affects. That being said, it's unpredictable and > unusual behavior for most people. There is a lot of > history and a lot of code that perhaps depends on it. > Shooting from the hip, tightening up traversal is > something that may be possible in the next major > release of Plone(6). However, maybe by then we have > some ideas on moving the traversal over to pyramid? :) > > - some people find acquisition powerful and use it > to solve problems in some wonky ways... > > - I would think any changes like this to traversal > are potentially very high risk with low benefits. This > might not be an important problem to tackle for you > right now :( > > > > Anyways, just some thoughts... > > > > > > -Nathan > > > > > > On Tue, Aug 19, 2014 at 4:02 AM, Mauro Amico > <mau...@gm...> wrote: > > I want to share a problem that I have with > ''publishTraverse'' and ''acquisition''. > > > > The Problem > > ----------- > > > > My problem with “acquisition” and publishTraverse is > that the current method returns too many different > URLs for the same content. For instance here is some > potential url for the “kb” page of the plone.org > website > > > > https://plone.org/documentation/kb > > https://plone.org/documentation/manual/kb > > https://plone.org/documentation/kb/manual/kb > > > https://plone.org/documentation/manual/spinner.gif/kb > > ... > > > > and here is a generic "Plone" site with two content > items "a" and "b" (folderish or not) > > > > http://example.com/Plone/a > > http://example.com/Plone/a/b/a > > http://example.com/Plone/a > > http://example.com/Plone/b/a > > ... > > > > All the urls above returns 200 with the same > content, while I would like the "canonical url" to > return 200 and the other to return 404. > > > > The behaviour described above constitute a problem > because: > > > > * multiple url for the same content is a problem for > SEO and is confusing to > > people. For SEO, in the latest versions Plone > introduced the canonical META, > > but IMHO it's just a workaround. People are > confused. For example: sometimes > > some of my editors ask me: "I can't remove the > http://example.com/Plone/a/b/a/ > > page. Can you do it for me?" > > > > * the page doesn’t seem really the same on all urls: > if you open > > https://plone.org/documentation/kb and > > https://plone.org/documentation/manual/kb the > second has a > > portlet that the first is missing > > > > * removing page from external cache (varnish or > squid), for example after a > > content modification, will be a pain, because for > the same content there > > could be multiple urls without any control or > rules (collective.purgebyid > > solve this) > > > > * when using subsite (or multiple plone site on the > same zope app) the problem is > > even more annoying: suppose that "a" is a subsite > (marked with > > INavigationRoot) for http://a.example.org and "b" > for http://b.example.org, > > opening the url http://a.example.org/b will > probably show the homepage of site > > "a" inside the "b" site (collective.siteisolation > and probably collective.lineage do > > something to isolate subsite, but IMHO again are > only workarounds) > > > > Are there other people with the same doubts and > problems? > > > > Does anybody have a good and stable solution for > that? > > > > My analysis > > ----------------- > > > > I tried to look in depth and identified a possible > source of the problem mentioned in: > > > > > https://github.com/zopefoundation/Zope/blob/2.13.21/src/ZPublisher/BaseRequest.py#L122 > > > > # And lastly, of there is no view, > try acquired attributes, but > > # only if there is no > __bobo_traverse__: > > try: > > subobject=getattr(object, name) > > # Again, clear any error status > created by __bobo_traverse__ > > # because we actually found > something: > > request.response.setStatus(200) > > except AttributeError: > > pass > > > > > > I found many solutions (like > collective.siteisolation) that work on higher level > > with IPublishTraverse adapter, but in my opinion the > problem is with all traversing > > (e.g. > https://plone.org/documentation/manual/spinner.gif/kb), so I think that at the end the best solution could be to modify the default traverser (or something > > like that). > > > > In a site in production using Plone 4.2, all content > are Dexterity, no > > portlet, I added a log: > > > > + import logging > > + logger = > logging.getLogger('analyze.publishTraverse') > > > > ... > > # And lastly, of there is no view, > try acquired attributes, but > > # only if there is no > __bobo_traverse__: > > try: > > subobject=getattr(object, name) > > + logger.warning("obj:%r name:%r > meta_type:%r", > > + object, name, > getattr(aq_base(subobject), 'meta_type, '-') > > + ) > > # Again, clear any error status > created by __bobo_traverse__ > > # because we actually found > something: > > request.response.setStatus(200) > > except AttributeError: > > pass > > > > After three weeks I checked the logs: some wrong > urls that I preferred they responded 404 and many > "false positive", which were fortunately all well > known: portal_skins object("FileSystem Script", ...), > Registry object ("portal_css", > "portal_javascript", ...) and the "Virtual Host > Monster" object. > > > > Probably I will extend logging period up to the > second week of September, after that I'm thinking to > monkey patch the method with something like: > > > > # And lastly, of there is no view, > try acquired attributes, but > > # only if there is no > __bobo_traverse__: > > try: > > subobject=getattr(object, name) > > + meta_type = > getattr(aq_base(subobject), 'meta_type, None) > > + if > meta_type.startswith('Dexterity ') or meta_type == > 'Plone Site': > > + subobject = None > > + raise AttributeError > > # Again, clear any error status > created by __bobo_traverse__ > > # because we actually found > something: > > request.response.setStatus(200) > > except AttributeError: > > pass > > > > Or > > > > # And lastly, of there is no view, > try acquired attributes, but > > # only if there is no > __bobo_traverse__: > > try: > > subobject=getattr(object, name) > > + meta_type = > getattr(aq_base(subobject), 'meta_type, None) > > + if > meta_type.startswith('Filesystem '): > > + pass # e.g. object inside > portal_skins > > + if meta_type.endswith(' > Registry'): > > + pass # e.g. portal_css > > + if meta_type == 'Virtual Host > Monster: > > + pass # e.g. VHM > > + else: > > + subobject = None > > + raise AttributeError > > # Again, clear any error status > created by __bobo_traverse__ > > # because we actually found > something: > > request.response.setStatus(200) > > except AttributeError: > > pass > > > > > > Opinions? > > Ideas? > > Better solutions (I really don’t like monkey patch > Zope2’s ZPublisher)? > > > > Thanks for the patience to read until here. > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Plone-developers mailing list > > Plo...@li... > > > https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > > > > > > > -- > > Nathan Van Gheem > > Solutions Architect > > Wildcard Corp > > > > > > ------------------------------------------------------------------------------ > > Slashdot TV. > > Video for Nerds. Stuff that matters. > > > http://tv.slashdot.org/_______________________________________________ > > > Plone-developers mailing list > > Plo...@li... > > > https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > _______________________________________________ > Plone-developers mailing list > Plo...@li... > https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Plone-developers mailing list > Plo...@li... > https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > > > -- > Nathan Van Gheem > Solutions Architect > Wildcard Corp > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Plone-developers mailing list > Plo...@li... > https://lists.sourceforge.net/lists/listinfo/plone-developers -- programmatic web development di(fh) johannes raggam / thet python plone zope development plone framework team member mail: of...@pr... web: http://programmatic.pro http://bluedynamics.com |