Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The latest release for this module was over a year ago. Since I have had to make a bunch of patches recently, I thought I'd post a github repository of the patched module for those who want the latest functionality (I don't have CVS access at drupal.org to github is just easier to share code).
Anyone wanting the latest updates to the module can pull the git repo from:
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | missing_argument.patch | 465 bytes | letapjar |
Comments
Comment #1
letapjar commentedOK the site changed my link: should be git://github.com/letapjar/mailing_label.git
Comment #2
acouch commentedI'm strongly against using this github repo and would ask that you remove it.
The front of this module says that the module needs a new maintainer, why not ask to maintain it here first?
Comment #3
acouch commentedSorry if that was too strongly worded.
I'm sorry I haven't been a good maintainer and I'm glad that you have been able to use the module and make updates to it.
I would like to discuss with you the possibility of taking over some of the module maintenance duties. That way you could 1) make updates directly to this project, 2) keep only one version of this module circulating which will make it a lot easier for users, 3) allow you to build up some of your drupal karma by making commits to this through drupal.org.
I can assist you with getting a git / cvs account if you are interested.
Comment #4
letapjar commentedI'm happy to help maintaining, the only problem is that I really don't know CVS. Git on the other hand I understand. I didn't mean to ruffle feathers by posting a repo - but it's been over a year since an update came out and even the changes I made were originally done many months ago. There was some discussion of becoming a co-maintainer when I originally posted the inline fields fix but that never went anywhere.
Other modules I've collaborated on use github to speed up development since several folks can contribute w/o needing cvs. I thought that this would do the same here (it is open source after all). I'm not trying to create a separate fork, but to actually use all the changes requires 4 patches at this point - much easier to have one place to pull from.
If you could point me in the direction of becoming a co-maintainer that would be fine - and what would be really helpful would be a git to cvs tool - I really will not have time to learn cvs just to post updates to one module.
If we can get these changes reviewed and committed I'll be happy to take down the repo as it would be redundant. Until then it actually serves a couple of useful purposes: 1) it's a way for folks to apply several patches in one go 2)It makes development easier (I travel a lot and use several machines - a repo on github is easy to access).
So - you could consider this my application to become a co-maintainer. I found this module to be very useful for some business needs (printing mailing labels for direct mail campaigns). When I found the inline field property not being picked up - I dove into the code and found a solution. In my own customizations I had changed a bunch of stuff and later found others wishing that only the inline fields problem be fixed. Learning from this experience and from other modules I've collaborated on (og_mailing_list), I have come back to this module to break up my changes into several patches that address individual issues. I hope that these changes can help make the module more widely useful.
Comment #5
acouch commentedhi letapjar,
Thanks for your response.
Drupal is moving over to git really soon. within a month or so i believe. so instead of having you banging your head on CVS why don't we wait until that change is finalized before you start committing to this project.
In the mean time I can make you a co-maintainer. I think you should apply for a cvs application. Once the git merge is completed I think this will give you a git account as well. The instructions are here: http://drupal.org/cvs-application/requirements
The instructions ask that you create an issue to be a co-maintainer. I'm already agreeing to this but it would probably be easier if you made a separate issue.
Comment #6
lonestar790 commentedIt is great to see these updates!! I had downloaded the module when it was available with the new updates.
I am getting an error:
warning: Missing argument 2 for mailing_label_pdf_form(), called in /sites/all/modules/mailing_label/mailing_label_plugin_display_attachment.inc on line 76 and defined in /sites/all/modules/mailing_label/mailing_label.module on line 87.
Thanks a ton. I look forward to getting this update.....
A
Comment #7
letapjar commentedthis appears to have happen from the multi-form patch - the currecnt display needs to be returned from the views plugin display attachemnt. Here is a patch.
Comment #8
lonestar790 commentedletapjar-
Thank you for the quick response. I have applied the patch and am no longer getting the error. My PDFs are now only producing the last field in the view on each of the labels. Anything before the last field is excluded. Any ideas?
Thanks again.
Comment #9
letapjar commentedIf you have those fields checked off as "exclude from display" on your view - they are excluded from the mailing label - see this issue:
If this is not working for you please post in that thread so I can follow-up and others can find the related posts.
Comment #10
hughbris commentedI have to admit I hacked your hack, latapjar, because your inline handling didn't quite work for me (I've forgotten why not, it was a whole 24 hours ago :)). I also simplified the way you did it because, well, I couldn't follow it. It's possible I wrecked something I didn't understand in that code block.
So we have a new fork on Github which obviously isn't a great situation. I am sorry, acouch, let's work on getting these changes into d.o and we can all be happy.
The problem is that I don't want to be a maintainer for this module either. Also, I am only a sandboxer at this stage. I am being upfront about it and am happy for this to be brought into d.o under GPL. Forks are not necessarily bad when they are pointed out.
Comment #11
letapjar commentedLooks right - but I haven't tried it out.
I was very new to drupal and unfamiliar with views when I wrote the original inline code.
You also added in a check for the 'exclude' option on the field which is probably good.
The code block you changed was pretty much local to the render function so your changes should be fine.
(note I only looked at the plugindispalyattachment code - not sure if you made changes elsewhere)
I'm working on another project with tight deadline at the moment, but when I get a chance to test your code I'll try to roll it into the inline branch on my repo.
Comment #12
bluegeek9 commented