FreePBX | Register | Issues | Wiki | Portal | Support

Developers, Developers, Developers, Developers

(TheJames) #1

Do you know PHP?
Do you know Asterisk?

Learning to develop for FreePBX may be intimidating. One of my goals is to change that and expose more developers to what is referred to as the plumbing.

Our DEV Team has put together some great information on our wiki:

There are different paths people take in learning a skill. We can relate these to swimming.

Toes in the water, 1 step at a time.
A good way to do this is to browse code at and look at how things are done. Once you have an idea of how things are done you can pull up and go through some of the issues and try and fix them. If you are feeling adventurous you may even go after a feature request. Then submit a patch/Pull request. Note we need a CLA on file which is explained in the wiki above.

Jump in where you know you can touch

You may do some of the stuff above but maybe you want a bigger challenge. There are some orphaned modules in Maybe take ownership of one of these and update it or do a full rewrite if needed. Look through the BMO stuff in the wiki and bring the module up to version 12.

Jump in the water with no idea of the depth
You may want to do the above stuff but maybe you want a bigger challenge. Create a module from the ground up. Follow through the WIKI info and look at various sources and make the next big thing.

No matter what way you like to approach it the WIKI can be very useful. If there is a subject in the wiki that you can’t find an answer for then tag me in a post in this section and we will work it out together.

Note I am a “teach the man to fish” type so I won’t write your code for you but we will make sure you get to the right place and document it along the way so others can find their path.

(Luis Felipe) #3

Hello: I’ve opened a feature request and I’m already working on it.

I’d like to know what’s the best approach on submitting changes/creating pull requests. The reason I ask is once the development env is set, you end up with remotes pointing to ssh://…

Also, there is no develop branch to branch off from. But I do see a develop branch on GitHub.

So should I fork the GitHub repo and then open a pull request on GitHub instead?

It is not clear how one should proceed after the dev env.

Any pointers would help. I’ve tried to find those info on the wiki but I couldn’t.

Thanks a lot.

(Jared Busch) #4

You want to fork it first.
Then pull your fork locally.
Commit to your fork.
Push to your fork.
Then when done, submit a pull req from your fork to the original.

(Lorne Gaetz) #5

Per the response to your ticket, you need a CSA on file for your code to be accepted.

(Luis Felipe) #6

Yes, I’ve done that and now I am in group ‘Developers-TOS’. Tks

(Luis Felipe) #7

Ok, Thanks.

(Luis Felipe) #8

Another help, please. The wiki page clearly says I should branch off from develop branch when working on a new feature, but I just realized the develop branch for the dahdiconfig module seems outdated.

For example, the file dahdiconfig/views/dahdi_analog_settings.php has the newest commit from 27 Nov 2013, whereas the same file has the last commit from 16 Feb 2015 in other branches.

So, from what branch I should branch off to start a new feature?

Thank you.

(Andrew Nagy) #9

I’m going to update that but you branch from whatever release/ branch you want to base your work off of.

(Luis Felipe) #10

Great. I’d like to start from release/14.0. Thanks a lot.

(Andrew Nagy) #11
git clone
git checkout -b feature/i-did-a-thing release/14.0
<do work>
git add -A
git commit -m 'I did some work'
git push origin feature/i-did-a-thing

Then initiate a pull request through Github

(Luis Felipe) #12

Ok. I forked from and was planning on working on it. But I can switch to GitHub. Thanks again.

(Andrew Nagy) #13

It doesn’t matter. is our primary but lots of people know and use github.

(Luis Felipe) #14

Sure, tks.