Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Plone 4.3 with p.a.widgets 1.x edit modals #720

Open
wants to merge 23 commits into
base: master
Choose a base branch
from
Open

Conversation

petschki
Copy link
Member

see issue #719

@petschki
Copy link
Member Author

bah ... sorry for the mess in here ... tried to squash some commits, but gave up ... nevermind.

@hvelarde hvelarde requested a review from rodfersou May 30, 2017 12:27
@@ -96,7 +96,9 @@ $(document).ready(function() {

TitleMarkupSetup();

if ($.fn.prepOverlay !== undefined) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changes on JS usually require an upgrade step to cook the resources; do you mind to check if we already have one in place?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done that

@@ -0,0 +1,50 @@
import pkg_resources

try:
Copy link
Member

@hvelarde hvelarde May 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is not necessary as this code will only be execute if plone.app.widgets is installed and you already are checking for that on configure.zcml.

also, for me is pretty important to document what you're doing here, so we can remove this in the future when we drop compatibility with Plone 4. that said, please add docstrings at the module and class levels explaining why this is needed..

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure .. you're absolutely right ... i'll remove that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we're still missing the docstrings.

@petschki
Copy link
Member Author

I'll try to fix the tests today ...

@petschki
Copy link
Member Author

petschki commented Jun 1, 2017

@hvelarde everything is green except one test in DEXTERITY_ONLY setup ... and I really do not know whats going wrong there. Can you give me some pointers? Could I add this test to the noncritical list (like issue_637 already is)?

@petschki petschki dismissed hvelarde’s stale review June 1, 2017 06:43

implemented suggestions

@hvelarde
Copy link
Member

hvelarde commented Jun 1, 2017

@petschki those are mandelbugs; I restarted the builds for you; what happened with the idea of working on this directly in plone.app.widgets? I don't see the point on adding something that we must remove later.

@petschki
Copy link
Member Author

petschki commented Jun 1, 2017

@hvelarde ah ... thanks for restarting. Now we're green. But you're right about RichTextWidget... let me check the pull request plone/plone.app.widgets#160 before merging this...

@petschki
Copy link
Member Author

petschki commented Jun 2, 2017

WIP: plone/plone.app.widgets#163

@petschki
Copy link
Member Author

petschki commented Jun 7, 2017

plone/plone.app.widgets#163 was merged right now ... I'll request a release of p.a.widgets and cleanup the unused code here.

@hvelarde
Copy link
Member

hvelarde commented Jun 7, 2017

do we still to add something in collective.cover, or just using the new widgets solve your problem?

@petschki
Copy link
Member Author

petschki commented Jun 8, 2017

@hvelarde unfortunately we still have to map a custom FieldWidget adapter for the RichTextField (like its done in plone.app.widgets.dx_bbb) ... see plone/plone.app.widgets#164 ... my latest pull request would fix this, so everything would work supermagically plone/plone.app.widgets#165

@hvelarde
Copy link
Member

hvelarde commented Jun 8, 2017

ok, just keep me updated :-)

@hvelarde
Copy link
Member

@petschki do you mind to make a rebase? also, do you mind to update me the status on this after the changes you made on plone.app.widgets?

@petschki
Copy link
Member Author

@hvelarde sure ... I'll rebase later today. the plone.app.widgets progress made the integration a bit easier, so we do not need to wire any widgets in collective.cover anymore. right now, it depends on the latest 1.x branch but I think we can have a p.a.widgets release 1.10 this week. I've also setup a testing environment for the widgets implementation but got stuck in robots test, not finding elements within the plone-modal ... need to do more investigations on that this week. I'll commit the 4.3.x-widgets travis-environment later today and put it to allow_failures ...

@hvelarde
Copy link
Member

we're having some mandelbugs with RF tests right now and I need to restart failing builds from time to time.

I think the problem on the new build you just created seems to be related with a feature removed from zc.buildout, but I don't remember very well and I'm not sure.

FWIW, buildout previously was able to downgrade itself and I think that's not the case anymore; that's why you're having:

VersionConflict: (zc.buildout 2.9.4 (/home/travis/build/collective/collective.cover/eggs/zc.buildout-2.9.4-py2.7.egg), Requirement.parse('zc.buildout==1.7.1'))

probably @idgserpro knows what is happening here.

@idgserpro
Copy link
Member

idgserpro commented Jun 27, 2017

We have good news and bad news. Let's start with the good ones, the reason (and a possible workaround) of the error.

When you use bootstrap.py, it downloads the latest zc.buildout (that now is 2.9.4). In bin/buildout it will point to /home/travis/build/collective/collective.cover/eggs/zc.buildout-2.9.4-py2.7.egg.

Here is the insanity: after bootstraping, when running bin/buildout, when downloading and extracting zc.buildout 1.7.1 for the first time when it's a direct dependency (install_requires) in an extensions section, it will give you the error: but if you already have a /home/travis/build/collective/collective.cover/eggs/zc.buildout-1.7.1-py2.7.egg in place, the buildout continues. That's why the error was happening only in the new job with the mr.developer in extensions, the old ones don't have mr.developer and had a cache that the new job didn't.

You can simulate it in your machine instead of travis, in a clean virtualenv environment (remember to comment a eggs-directory in ~/.buildout/default.cfg if you have it in place). Funny thing is: the first time you run it will break (giving the error), but the second time won't, because you now have a zc.buildout-1.7.1-py2.7.egg in your environment.

The bad news: It seems that it started in zc.buildout 2.9.x branch (https://travis-ci.org/collective/collective.cover/builds/247259422) but we don't have time to check exactly what happened to start having this issue. As miohtama used to say, life is hard and Plone is harder™.

setuptools have the same issue as zc.buildout above: travis decides to automatically install some packages and setuptools is a direct dependency from some of them (the specific versions can be checked here).

There are two immediate workarounds:

# VersionConflict: (zc.buildout 2.9.4 (/home/travis/build/collective/collective.cover/eggs/zc.buildout-2.9.4-py2.7.egg), Requirement.parse('zc.buildout==1.7.1'))
# We still don't know why this happens. It seems that when using extensions with a package that
# requires zc.buildout (like mr.developer).
zc.buildout = 
# XXX: Same as above.
# VersionConflict: (setuptools 12.0.5 (/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages), Requirement.parse('setuptools==20.1.1'))
# travis has some packages installed by default in it's virtualenv and setuptools is installed.
# https://docs.travis-ci.com/user/languages/python/#Pre-installed-packages
setuptools =
# XXX:
# Trying to pin in versions-4.3.x-widgets to the latest version it works but then all tests break.
# So we're going to use the same versions that Plone uses in it's versions.
- PLONE_VERSION=4.3 WIDGETS=true BOOTSTRAP_PARAMS="--buildout-version=1.7.1 --setuptools-version=20.1.1"
(...)
python bootstrap.py $BOOTSTRAP_PARAMS

Bad news part 2: now you have 20 failed tests after solving the VersionConflict. @petschki, can you try to run locally and see if this happens only in Travis?

Another question: why are you pinning plone.app.widgets = since you're already checking it's branch in sources?

@petschki
Copy link
Member Author

@idgserpro thanks for the details ... pinned everything down and removed unneeded version pin of plone.app.widgets. not the buildout runs smooth ... I'm aware of those 20 errors. thats why I moved the environment to allow_failures ..

@idgserpro
Copy link
Member

You don't need the two pins, only one of them. It's a good practice as well to document the pins in the cfg itself, so in the future if you try to remove them its less work to know why it was pinned. Our suggestion to doc above the pins:

# XXX: https://github.com/collective/collective.cover/pull/720#issuecomment-311383938

@hvelarde
Copy link
Member

hvelarde commented Jun 27, 2017

I'm not sure which one would be best practice here; I guess we should ask.

@idgserpro
Copy link
Member

idgserpro commented Jun 27, 2017

I think we should open an issue at zc.buildout exposing the problem and, from there, we can know which one is the best approach.

From a Plone perspective, since they are planning to get rid of bootstrap.py, they will probably be in favour of changing cfgs.

twitter bootstrap sets its .hide class to `display:none !important` so
we do not get any configure modal at all when assigning hide class in
templates ... use the strategy to set `.modal { display:none }` like
bootstrap does...
if($("body").hasClass("pat-plone-widgets")) {
// XXX: reload tile content asynchronously here when destroying the modal
// need to find the right event where to hook in
return // exit here
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

miss semicolon here

Copy link
Member

@hvelarde hvelarde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the branch is outdated; a review is not possible in this state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants