Looking at http://blog.worldempire.ch/de/api/function/hook_privatemsg_block_message/1, the documentation there is quite outdated..
http://blog.worldempire.ch/de/api/function/hook_privatemsg_block_message... should be backported. Note that some things need to be updated, for example the return value is different. See also http://blog.worldempire.ch/de/api/function/pm_block_user_privatemsg_bloc....
Someone wants to give this a try? No coding skills required, only documentation improvements...
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 877598_3.patch | 2.69 KB | Bilmar |
| #14 | 877598_2.patch | 2.69 KB | Bilmar |
| #9 | patching.zip | 9.61 KB | Bilmar |
| #6 | 877598.patch | 2.68 KB | Bilmar |
Comments
Comment #1
berdirWrong version...
Comment #2
Bilmar commentedHey Berdir,
yikes - I checked this out really wanting to help but having trouble. I noticed the 6.x-1.x version has $recipient where as 6.x-2.x has $recipients. Does this mean in 6.x-1.x you are only able to send a message to one user at a time? I see in the above instructions that the code needs to be backported, and that the return value $blocked needs to be changed?
Thanks
Comment #3
berdirFunctions that start with hook_ are for documentation purposes only. They are not actually called, the only thing that is called are the implementations of that hook.
In this case, we simply forgot to update this when we changed the function from a single $recipient to multiple ones.
Basically, the following needs to be changed:
- Switch to $recipients
- Copy the content of the pm_block_user_block_message() to this function to have an example.
- Copy the documentation block from the 6.x-2.x version
- Because only the 2.x version supports different recipient types and 1.x only users, change the part "with the keys recipient ({type}_{key}) ..." to "with the keys uid ..."
- I just notices that also the 2.x version still uses $recipient to document the param. That needs to be updated in all version, but first, start with 1.x.
Just ask if you have more questions...
Comment #4
Bilmar commentedI hope I am heading in the right direction with this =/
I removed the following lines as from my understanding of your explanation above, 6.x-1.x doesn't support checking for roles. Not sure if this is the correct thing to change.
After your next advice/review when you have time, I will make more changes or create the changes as a patch (I have re-read instructions on creating patches and have tried it several times before).
Comment #5
berdirYes, this looks good.
You don't need to remove the roles part, that is a required check and has nothing to do with sending messages to roles. So, after re-adding that, you can create a patch. If you have problems with that, join #drupal-games and I'll help you.
Comment #6
Bilmar commentedJust to see if there is a better way of patching from what I am doing:
1) I created a duplicate of privatemsg.api.php, made changes and saved as privatemsg.api2.php in the privatemsg folder
2) with terminal opened the privatemsg folder
3) created patch with diff -up privatemsg.api.php privatemsg.api2.php > 877598.patch
4) opened 877598.patch and changed name privatemsg.api2.php to privatemsg.api.php at the top
to
Thanks!
Comment #7
berdirIf you use CVS, it is way easier :) As you are using OSX or Linux and you are already using the terminal, the switch should be easy.
Installing CVS on Ubuntu/Debian is very easy (sudo apt-get install cvs cvsutils), on OSX, there is a lullabot video http://www.lullabot.com/videos/install-cvs-mac-osx :)
Every project has a "CVS Instructions" local task, you can configure which branch you want to work on then you you only need to copy & paste the commands from there. For Privatemsg 6.x-1.x, this is the direct link: http://drupal.org/node/3279/cvs-instructions/DRUPAL-6--1
Once you have your CVS checkout, you only have to remember a few things.
Once you made the changes, create a patch with:
It doesn't matter how you name your patch as long as you don't use whitespaces. The command automatically compares your local files with the original files on the server, so you don't need to make local copies or changes to the patch file. Just make sure to patch from the top-level directory.
To revert all your changes in your checkout, you can use this:
When you want to update without loosing your local changes, leave out the C option. You can also switch between different branches with the -r argument (for example cvs up -dP -r DRUPAL-6--1). Note that for switching to HEAD (which is currently 6.x-2.x), you need to use cvs up -dPA instead.
Now to your patch.. looks good except of a minor issue:
There are some unecessary whitespaces on that line...
There are some whitespaces on the empty line. You can see these easily by using Dreditor:Dreditor.
Comment #8
berdirComment #9
Bilmar commentedoh wow, Dreditor is cool. I hope to learn how to use it more in the coming days/weeks
I'm not sure what happened with the below part getting into the patch:
The files I used in creating the patch with command
diff -up privatemsg.api.php privatemsg.api2.php > 877598.patchare attached in a zip. I wasn't able to find any spaces around the area above =/I am going to look into the CVS method =) Thanks!
Comment #10
Bilmar commentedComment #11
berdirI hope you didn't give up after trying to learn CVS.... :)
Comment #12
Bilmar commentedHey Berdir,
Sorry for the big delay on this. I did run into walls getting CVS installed on my ancient MacBook but as i was about to start tackling how to use CVS i had to travel the past several weeks for work. I fly back into Tokyo (home) on Friday and promise to have this done this weekend.
If you have any tutorial guides on what to do once CVS is installed I'll read it on my iPhone to prep for the major learning I'll be doing this weekend =) I'm excited to learn the basics of how it all works to contribute in other areas in the future. Thanks
Comment #13
berdirNo problem, I was just wondering if you gave up or something :)
This isn't critical so feel free to get back to it when you have time. I can't tell you much more than what's in #7. I think the best option if you have any specific problems is joining #drupal-games and ask me directly ((or ask someone else in #drupal-contribute if I'm not around).
Comment #14
Bilmar commentedoh man, this stuff is hard x_x
I don't have my macbook with me for the next week so I started over and attempted to use Git on my Windows. Please let me know if the attach file is better than my first attempt =)
After making changes to the privatemsg.api.php file, I used the command
git diff --no-prefix --relative > name.patchto create the patch. I saw this on a drupal.org page when searching how to create a patch with Git but not sure if there is a better way.Comment #15
berdirGreat :)
At a first glance, the patch looks good. Let's see if it applies on the testbot.
I never had to use the --relative command but other than that, I don't think there is an easier way.
Good side of the story is that you're set up now.. Once this is commited and you want to work on a different page, just remove all local changes (if you haven't commited anything to your local git checkout) with "git reset --hard". Then, apply patch/work until you're done and create a new patch.
Comment #16
Bilmar commentedAwesome =)
I used Dreditor to review the patch and see a red highlight. Is this not good / should this be removed?
http://www.screencast.com/users/trupal218/folders/Jing/media/dad8122f-59...
The way I worked on the latest Privatemsg with Git was by downloading it from http://drupal.org/project/privatemsg, putting the folder into the git folder on my local drive, committing the whole folder, then made edits and created the patch. Is this the only way? Or is there an easier way I can link up to the latest Privatemsg module by a url link and update it with a command?
I installed the two programs below and made C:\testgit\ my git repository
1) Git-1.7.0.2-preview20100309.exe from http://code.google.com/p/msysgit/downloads/list
2) TortoiseGit-1.5.2.0-32bit.msi from http://code.google.com/p/tortoisegit/downloads/list
I'm going to continue to read up on Git this week =)
Comment #17
berdirThat red thing means that there are unecessary whitespaces on that line. Would be great if you could do a re-roll and remove them.
Regarding git, drupal.org has now an official git mirror from which you can clone. That will also become the official repository once we're (finally) moving to GIT, so you're already prepared for that then.
The Clone-URL is this: git://git.drupalcode.org/projects/privatemsg.git
Note that you need to use the 6.x-1.x branch for this issue.
If you work in different issues, you might want to read http://groups.drupal.org/node/91424. Contains a nice description of a workflow but you will have to translate that to GUI actions :)
Comment #18
Bilmar commentedThanks for the good info! I have lots to read up this week.
I think the text editor I use (Notepad++) added the indentation with spaces. I removed them and will check with Dreditor again once uploaded (I wish there was a way to use Dreditor before uploading, or maybe I need a better text editor). Also, I used 6.x-1.x-dev for the patches for this task.
Thanks again
Comment #19
berdirSome editors have options to automatically remove things like trailing whitespaces when you save a file.
The problem is, that usually doesn't work well when you work with patches. Changes are that there are a few whitespaces in the file already that you are working on and if you save that and then create a patch, it will contain these changes too.
If you do that twice, then one of your patches won't apply anymore even if they were totally unrelated if the other gets commited. Not speaking about other patches that you are breaking that change some code where you remove whitespaces :)
So I think the best option is to live with having to upload the patch a second time if you miss one of these.. :)
Comment #20
berdirOh, btw, I think this is ready now, will commit soon.
If you want to help elsewhere, you can have a look at this issue #859144: Add a README file for better documentation. BenK already started there but could need some help. My suggestion would be that both of you write a part of it and then cross-read. You probably want to talk to him to define who writes what. He is also in #drupal-games quite often (right now as well).
Comment #21
berdirCommited, thanks for working on this!
Comment #22
Bilmar commentedThanks, I really appreciate your instructions and advice as I get to know the ins-and-outs of the process.
I hope to help out with the README which BenK has been writing.