Thanks @cewing for your help. I will be happy to contribute to this community and be a part of this project
I am Akshat Jhanwar a final year student and I am coding in python for over 5 years now. I have done 3 internships in software development cumulatively spanning over 9 moths. I have worked with a lot of python frameworks including django and Opencv. And have used some cms software such as drupal, joomla while doing freelance web development. I would love to contribute towards this amazing project.
Welcome, @akshat! We're glad you've chosen to visit the Plone community. There is a post just above yours from me with some more information you might want to read. And do please get started by reading and following the basic instructions at the top of this community forum post. You've already taken the first step!
Let us know what we can do to help you as you start to learn more about Plone and what it can do.
Thanks @cewing for your help.....I would love to contribute towards this project .
Hi @cewing! I'm Vedant and I was going through the ideas list for Plone for this years Gsoc and I found this idea interesting. I have experience in python development in general, and I'm more than willing to pick up whatever skills may be required for this project. Also, I have some experience in testing.
I was wondering what the current status of this project is, and how I should start preparing for my application. I haven't contributed to Plone as of yet, so if you feel like theres a bug I could pick up to get better acquainted with the codebase, I'd love to give it a shot.
Also I understand that this may be a little late to express my interest, but I'm hoping that would not be an issue.
Greetings, @vedantc98, and welcome to the Plone community. We are glad you're here and interested in working with us for your GSoC experience.
You should begin by following the five steps outlined at the top of this post. That is the best route to begin learning about Plone: what it is, how it works, and how to develop for it.
Once you've built a basic Plone website, and worked on some simple issue, you'll want to focus your attention on two packages in particular: Products.membrane and dexterity.membrane. The core of this project involves cleaning up the code for those two packages and merging them. The former package represents the old way of doing things, the latter package is the new way.
You'll want to reach out to @jensens and @mauritsvanrees as well as @agitator, all of whom have experience in this part of the Plone code base and can help you begin to establish an idea of what needs to be done.
Hoping this helps you to get started,
Thanks Cris, that will help me get started
I'm really excited to contribute!
I'll get the initial development setup done right now. Once that's done, should I use this forum or another channel like IRC or GItter to approach the members you've named?
@cewing Hi, I'm actually having a little difficulty setting up the environment.
I've installed Plone and then tried to create a website, but I cannot access the site because of the following error:
python(43172,0x70000f76b000) malloc: *** error for object 0x7fe70a1988e0: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
I tried changing my python version to 2.6 using a conda environment, but that didn't seem to help.
Any ideas whats causing the issue? Thanks!
Hi, I finally have my initial setup done and was going through the documentation and the project proposal.
This is my understanding so far :
Product.membrane is essentially a framework to create users as content, and a standard implementation of this framework is Product.remember.
I understand that Archetypes is the system that is used for Product.membrane and consequentially Product.remember.
Similarly dexterity.membrane is a kind of framework written with in Dexterity instead of archetypes, and also comes with an example implementation.
So essentially what this project involves is(roughly speaking) merging these two modules while refactoring the code.
I have a few questions here :
What will happen to Product.remember when we merge the two modules?
Is dexterity.membrane simply a port of Product.membrane to the Dexterity system, or is it built on top of Product.membrane?
Dexterity (Plone 5) replaces Archetypes (Plone 4).
You will nothing to do with Archetypes. It's a dead end.
You've got it more or less correct.
When you look at Plone, it consists of layers. The basis is Python, on top of that Zope, on top of that the CMF framework (these days a pretty small layer), and on top of that we have Plone.
Products.membrane started out as a framework for creating users as content, which only needed the CMF layer. Maybe even only the Zope layer, but I think CMF was needed. When I look at the latest release, it depends on Plone, so we can ignore compatibility with lower layers. So: it is the basis for users-as-content in Plone.
When you install Products.membrane, you do not yet have a content type that represents a user. Well, there are example types in the code. But as integrator you can create your own content user type that uses Products.membrane. I have one really old Plone 3 site in which I (or colleagues) have done that.
For building content types in Plone, you used to have only one option: Archetypes. Products.membrane did not use this, apart from maybe the example types. The standard add-on for users-as-content was Products.remember. This was built on top of Products.membrane and was using Archetypes as basis for the content type.
Then dexterity came along as option for creating content types. In Plone 5 this really has won the battle with the old Archetypes. If you create a content type in Plone 5, you should use dexterity.
That is what dexterity.membrane is: users-as-content with the dexterity content-type framework as basis, and still building on Products.membrane.
So Products.membrane is the basis, and it is content-type agnostic: it does not use Archetypes or dexterity, and does not mind which of the two frameworks you choose.
For the GSOc, as I understand it, the idea would indeed be to merge Products.membrane and dexterity.membrane. That should simplify the combined code.
To answer your questions:
- Products.remember would still continue to exist, but it does not need to be touched in this project, and it should just use the current version of Products.membrane. The future version of Products.membrane would be incompatible.
- dexterity.membrane is a port of Products.remember to the dexterity system. It is built on top of Products.membrane.
@mauritsvanrees, Thank you so much for breaking that down for me, it makes things a lot clearer.
I have a follow up question, as @jensens has mentioned earlier in this thread:
Isn't Archetypes already an 'optional feature' since it is content-type agnostic?
So basically what is required to be done is keep the Products.membrane framework as it is, and include the Dexterity implementation(dexterity.membrane) in the same package as the canonical implementation.
Also if you could set me up with a few resources(documentation links or even bugs that I could try to fix) that would help me get acquainted with the code in Products.membrane or dexterity.membrane? I went through the documentation for those two modules, but I'm still in the process of figuring out the codebase.
I want to start working on my proposal for this project, so I'd love to get a rough idea of what to look at (considering how big the codebase is).
@vedantc98, you've still got a bit of confusion. Archetypes is a content type framework, so it is not content-type agnostic. It is the basis upon which older content types in Plone were built.
Dexterity is the basis on which new content types in Plone are built. It is the content-type framework which is now used by Plone by default.
It is still possible to use Archetypes content-types in Plone, but the Archetypes framework is now optional and most Plone installations will not include it. The point that @jensens is making is that since Archetypes the framework is optional, it should also be the case that it is optional to use it when using Products.membrane. Right now it is not. If you install Products.membrane, you must also install Archetypes because it is a dependency, and not optional.
I'm sorry, that wasn't clear from my post.
In any case, that does answer my question since Archetype is a dependency for Products.membrane
IIRC, one reason that Archetypes is currently still a dependency of Products.membrane, is because Products.membrane installs its own catalog.
A catalog in Plone offers a way to search for items in the Plone database (ZODB, Zope Object DataBase) without 'waking up' all objects. The catalog has indexes, just like PostgreSQL or MySQL. The standard catalog in Plone is an object with the id 'portal_catalog'. It is used heavily in Plone for building the navigation and of course for the search form.
Products.membrane uses its own catalog, with the id 'membrane_tool'. This was originally done to avoid adding even more indexes to the already index-heavy portal_catalog.
Problem: whenever a user-as-content object gets changed, or added or deleted, all catalogs must be updated. For the portal_catalog this happens automatically. For all other catalogs, you currently need Archetypes. It has some code and configuration that allows you to say: "when an instance of this portal_type (some user-as-content type here) gets updated, Plone must inform this extra catalog as well (membrane_tool here)."
The consensus seems to be that it is better to put the extra indexes (and metadata) that Products.membrane needs, into the original portal_catalog. That would mean we can lose the dependency on Archetypes.
Yes, that is the idea.
Actually, from looking at https://github.com/collective/Products.membrane#requirements this is no longer the case. For updating multiple catalogs, we no longer need Products.Archetypes, but can use collective.indexing, and that package has actually been merged into Plone 5.1. My memory on membrane is rusty: I am not using it in any current projects.
Yes, it is big. Or at least the Plone code is big, and you may need to get acquainted with lots of its code. Or at least a bit more familiar with several concepts used throughout Plone.
This issue seems to be the birth of the idea of merging Products.membrane and dexterity.membrane: https://github.com/collective/Products.membrane/issues/4
Products.membrane does authentication, so it helps to know how authentication in Plone works. The basis is the
acl_users object in Plone, which is the central part of PAS or Products.PluggableAuthService. It is 'pluggable', which means you can write plugins to add new features. Products.membrane is such a PAS plugin.
It could be interesting for you (or others considering this GSOC project) to compare the standard user management plugin from PAS (which would also work on bare Zope) with the Plone specific user management plugin in Products.PlonePAS and the membrane user management plugin. Maybe compare a recent LDAP plugin too.
Thanks for helping me out with trying to figure out the code!
You said that:
Does this then mean that Product.membrane is independent of Archetypes? I went through the source code again, and IMHO, the only places we need to use Archetypes are for the examples or the tests. The only case in which we would need Archetypes would be if we decide to implement an AT membrane type. Did I get that right?
@mauritsvanrees It seems like Products.membrane still depends on the AT framework for implementations of the Authentication interfaces. For example in the following line:
We use the implementation of the
IMembraneUserAuth interface which is written in
Which has Archetype dependencies. Is this the kind of thing we're trying to eliminate in this project?
Look a few lines above the line you are quoting:
The code says:
auth = user_ifaces.IMembraneUserAuth(member, None)
This code looks for an 'adapter' from
member is an Archetypes object, then it will find the implementation that you reference. If
member is a dexterity object, then it will either find something else (like in
dexterity.membrane) or it will find nothing and you get some kind of error.
As you can see, this can get complicated and confusing, which is indeed what we want to get rid of.
'Adapters' are part of the Zope Component Architecture, which is used heavily throughout Plone. It is powerful and makes much of the flexibility and pluggability of Plone possible, including the whole PluggableAuthenticationService. Some documentation: