OG-ification - I'll do it. Are you interested?
| Project: | E-Publish |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
I'm just starting the OG-ification of this module. The end result I'm going for is that organic groups can each have multiple publications visible only to group members or marked as public for general viewing. Public pub's would have three options - make all nodes public, select which nodes are public (checkbox style), and allow authors to determine node visibility. I'd also keep the ability for site-wide publications. I think this will probably depend on og_vocab to allow each group to have its own taxonomy for articles - i.e a group about cars doesn't need a term created for a horse riding group. However, I'd also allow a site-wide taxonomy to be used as well - perhaps containing general terms? Not sure how that will work yet. Also, any listings of pub's would be limited to what a particular user has permission to view - i.e. site-wide, subscribed groups, and public pubs from unsubscribed groups. Controls will have to be modified to consider partial-public pub's and skip over non-public nodes for users that shouldn't see them. Yada, yada, yada, etc.
So I'm posting here to see if the author of this module is interested in such a development and if so, how you'd like to handle it. I'm also interested to know whether the users of this module are interested in this and what they think should be included. For a first run at this, I just want it to work with the minimum of changes required.
If the author is not interested in this, I will create a splinter project of my own.
I have started going through the code and making preliminary notes on where I need to change things. I have applied the patch on http://drupal.org/node/160468 - thanks for that - so I think the outstanding bugs have been taken care of.
#1
Also applied http://drupal.org/node/147889 to my copy. Anything else I'm missing?
#2
What is this function there for: section_form() ? I don't see that it gets called from any other function. It isn't used?
#3
Another mystery function: epublish_sec()???
#4
Here's another one: epublish_edition(). Is it called somewhere?
#5
I think this is the last of the mystery functions: epublish_headlines(). Do all of these maybe get called by some other module and these are here for compatibility maybe? Or are they leftover from previous changes?
#6
This is a great idea!!! I was actually trying few work-arounds to e-publish through conbiing it with OG... though unsucessfully.
I would love to see somthing like this developed, but unfortunately I'm not a programer. But nevertheless I'm sure it would be very useful for many people.
So basically, if they want to start an eJournal they would first need to register as an OG, right? Which is cool because then they could have their own forum and calendar and theme -- and generaly a community feel.
I think Admin should have a choice on how many publications to allow for each OG. I would assume, 1 by default to avoid confusion.
Groups, usually after the phase of "getting together" soon want to start their own publication (journal or a newsletter). But the existing river-of-news view in OG is not exactly a Journal type view like the one that E-Publich module offers, which is excellent for eJournals.
There also if an eJournal module which has some very cool workflow features, but it works only for 4.7. They said that they are going to start work on exporting to 5.1 few months ago, but there's still nothing.
I think the important thing to sort out would be how to make sure that each journal editor sees only those nodes that he is supposed to see when he is making a sellection and not all other nodes designated for other eJournals. I think sorting out this aspect would be a key to making it user friendly ... so that any user can easily start an e-journal and easily add nodes to that publication.
#7
@matrixfighter -
That's actually the easy part, I think. At least, in my mind it is not unreasonable to require that OG publications use content from their own OG. So that's just a SQL query change.
Regarding workflow, I'll probably not add anything formal (presumably all content is generated prior to creating a given edition) and at least for content, the workflow module should be fine for that. What I will be adding are about 6 or 8 new permissions which assume that non-admins are creating and editing publications. I'll further divide publications into site-wide and OG types with different permissions for each. That way, if an admin wants to maintain a site-wide pub, he's welcome to.
I'm also probably going to require og_vocab for the OG portion to work. I'll be looking at the module in just a few minutes from now actually. I hope it does what I expect. On top of that, I'm not going to require OG. I'm going to try to switch between existing code and the OG-ified code so that users have a choice.
I probably won't limit the number of pub's per group simply because it should obviously become a hassle the more you create and should therefore limit itself.
#8
I would be interested in this module.
It would be nice to have each publication its own theme. Or some way to atleast upload their own CSS file. Otherwise all publications will look the same.
#9
I'll be doing it. I just have to fit it into my schedule. Might be a while, but not like a year or anything.
#10
OK. I'm doing phase one, which is to just get the group context set based on the first article in the publication edition you are viewing. I'm having trouble setting context as noted here: http://drupal.org/node/213182
Could someone outline the steps (function calls) that are made when I view an edition of a newsletter? Some of the functions didn't quite make sense to me (simply because they weren't how I would do things) and with a bit of a lack of sleep lately, my brain is not cooperating on this project.
I'd still like to do a total og-ification at some point where each group can make its own publications, but this will do for me for now once it works. I'll post the patch here when I'm done and hopefully it will benefit some of you.
Right now, the only thing I can think of to set the group context, based on moshe's comment in the linked issue, is to provide an alternate menu structure if a setting is checked to associate editions with groups. It would be a global setting for now. Hopefully, if someone gets back to me on my question above, I'll come up with a better solution.
#11
So, I took a nap and figured this out. I'm going to be lame and attach the module file rather than a diff. The reason is that my 'universal' diffs never seem to come out right for the Drupal users even though I've followed the handbook. They work fine on my system, so I must have some kind of unique setup. I hope someone can post a diff for others to use.
Warning, this includes my other changes over here: http://drupal.org/node/150857 as well.
I have also updated the layout files if you are interested. I'm attaching a new layout file which shows the publication edition like a newsletter with full nodes. You may have to tweak your css files. I don't know what it looks like with the basic css.
Obviously, remove the irrelevant extensions from the files before use.
#12
+1 this is an interesting idea. what became of it?