I want to learn to code addons for Xenforo. I have specific experience, where do I start?

[SneakyDave]

This is a long way from what I currently do - run stuff on the sandbox.

That works great for most projects, and some echo statements carefully placed, but it gets harder to do that when debugging JavaScript or Ajax requests

 

[sbj]

finding out what objects and variables are available, etc.

Can you explain further? I mean explain how to do that?

 

[SneakyDave]

With PHP storm? I'll send you a PM for discussion

 

[Stuart Wright]

Being able to produce addons for Xenforo requires competency in PHP, SQL, JavaScript and Ajax, CSS and skills in UI implementation and design. Did I omit anything?
That's a considerable set of qualifications.
Are all Xenforo addon developers equal or are some better than others? Are some addons poorly coded? Are the queries always efficient and scalable for large communities?
How dependable have amateur addon developers traditionally been? Yes some have provided excellent addons with top notch support, but how many admins have found themselves with unsupported addons after developers have moved on?
I would like to get into Xenforo coding so I can better support my own website and maybe release addons at the same time. I have more relevant experience than most but even with running AVForums as a full time job, I find myself short of time and skills to start the long haul up the learning curve.
What I need is to pay someone to help me set up a development environment on my computer and teach me what I need to know to get going. Probably with Xenforo 2.
I think the boys ought to consider setting up courses of various lengths for various skill levels for people wanting to learn to code Xenforo. They could increase the number of developers working on their platform and make some money at the same time.

 

[Robust]

PhpStorm is recommended by many because it is just really good. I come from a background using JetBrains IDEs for a long time, I used them back in my Java days after spending ages with uncomfortable IDEs and IntelliJ IDEA just clicked. The obvious choice was PhpStorm for working in PHP and it's been a great decision.

There is no 'best IDE' - an IDE is there to help and ease what developers need to do with features that assist. Whatever is best for you is the best IDE, if PhpStorm isn't what you're looking for, find what you are. That said, expect to be confused initially, it'll likely lose your love for a specific IDE though.

Being able to produce addons for Xenforo requires competency in PHP, SQL, JavaScript and Ajax, CSS and skills in UI implementation and design. Did I omit anything?

Those would be the ideal world, realistically the bare minimum is somewhat competent in PHP, HTML and usually SQL.

My Ajax skills are minimal to none, for example.

 

[Xon]

Being able to produce addons for Xenforo requires competency in PHP, SQL, JavaScript and Ajax, CSS and skills in UI implementation and design. Did I omit anything?

As long as you aren't designing complex stuff, the XenForo-provided defaults mean you don't need overly complex javascript/ajax/css.

And most developers have a poor understanding of SQL, especially of SQL running on a busy forum.

 

[Robust]

As long as you aren't designing complex stuff, the XenForo-provided defaults mean you don't need overly complex javascript/ajax/css.

And most developers have a poor understanding of SQL, especially of SQL running on a busy forum.

Following from Xon, in modern frameworks (hopefully XenForo 2) queries aren't done much manually. For example, all my apps in Laravel I don't think I've wrote one raw SQL query.

 

[Chris D]

hopefully XenForo 2

Definitely XF 2.0.

$post = $this->finder('XF:Post')
    ->with('Thread')
    ->where('post_id', 2)
    ->fetchOne();

Instead of:

$post = $this->_getDb()->fetchRow('
    SELECT post.*, thread.*
    FROM xf_post AS post
    INNER JOIN xf_thread AS thread ON
        (post.thread_id = thread.thread_id)
    WHERE post_id = ?
', 2);

 

[sbj]

Being able to produce addons for Xenforo requires competency in PHP, SQL, JavaScript and Ajax, CSS and skills in UI implementation and design. Did I omit anything?

You need to start somewhere and start little.
You need to set a goal for yourself which you can reach and slowly progress to that.
If your expactations are to code big add-ons in a short time, then of course you will fail.
From what I have seen, for little stuff all you need to know is PHP and SQL knowledge.
I am in the same boat as you. Don't setup too big expactations. Start little. I mean, let's say you coded one little add-on for your site. That means 1 add-on you are not dependant on anybody. A win-win.

 

[Jake B.]

What does that do?

it'll copy the full reference for a function. So if I use it with my type cursor in 'getCopyrightHtml' inside of library/XenForo/Application.php it'll copy this:

\XenForo_Application::getCopyrightHtml()

Not as useful when you're not using namespaces, but works beautifully in javascript. I can just copy and paste this:

uix.checkRadius.resize()

 

[Chris D]

Huh that is useful... thanks!

 

[Robust]

Definitely XF 2.0.

$post = $this->finder('XF:Post')
    ->with('Thread')
    ->where('post_id', 2)
    ->fetchOne();

Instead of:

$post = $this->_getDb()->fetchRow('
    SELECT post.*, thread.*
    FROM xf_post AS post
    INNER JOIN xf_thread AS thread ON
        (post.thread_id = thread.thread_id)
    WHERE post_id = ?
', 2);

Think you should have an ORM like Laravel.

$post = Post::where(['post_id' => '123'])
->first();

$post->thread()->id; (dynamic fetching of the associated thread)

I believe it also caches data so it's efficient for larger boards. Might want to include its logic but depends how far into XF 2.0 you are

 

[Chris D]

It's essentially the same thing, though it's our own so we have made it and will make it into what we need.

$post = Post::where['post_id' => '123']
->first();

This is equivalent to:

$post = $this->finder('XF:Post')->where('post_id', 123)->fetchOne();

$post->thread()->id;

This is equivalent to:

$post->Thread->thread_id;

You'll notice when we fetched the post, we didn't specify "->with('Thread')", but regardless we can still call "->Thread" which dynamically fetches the appropriate Thread object.

 

[Robust]

It's essentially the same thing, though it's our own so we have made it and will make it into what we need.


This is equivalent to:

$post = $this->finder('XF:Post')->where('post_id', 123)->fetchOne();

This is equivalent to:

$post->Thread->thread_id;

You'll notice when we fetched the post, we didn't specify "->with('Thread')", but regardless we can still call "->Thread" which dynamically fetches the appropriate Thread object.

Nifty, sounds good. Can't wait

 

[Chris D]

This isn't really new info, btw, we talked about it a while ago

https://xenforo.com/community/threads/xenforo-2-0-development-updates.113262/#post-1044323

(We're off topic now)

You need to start somewhere and start little.
You need to set a goal for yourself which you can reach and slowly progress to that.
If your expactations are to code big add-ons in a short time, then of course you will fail.
From what I have seen, for little stuff all you need to know is PHP and SQL knowledge.
I am in the same boat as you. Don't setup too big expactations. Start little. I mean, let's say you coded one little add-on for your site. That means 1 add-on you are not dependant on anybody. A win-win.

This is a good tactic.

My first add-ons were just essentially template modifications. My first add-on that used any sort of JavaScript was probably a year or two later.

The only good thing about template hooks back in the day was it was a really simple way to expose you to PHP. In some ways, I'd probably still recommend that as a starting point, as long as you then remember that you shouldn't use template hooks any more and only use the Template Modifications stuff

 

[sbj]

This is a good tactic.

My first add-ons were just essentially template modifications. My first add-on that used any sort of JavaScript was probably a year or two later.

Yep, that is how I approach it now. It is better to start somewhere and doing little stuff, than waiting for someone else creating it (if at all).

My only "discouragement" is that XF2 is on the train waiting for the arrival, where I have to learn a different approach. So it doubles the effort. But better starting now than never.

Btw. I was able to follow your instructions told here (by using XAMPP) and after that some steps are missing I guess. Cause to be able to run XF on localhost, we still need a database, so after that we have to create a database and connect to it. Just saying it for people who also are in the same boat, of course you know that already.

 

[Chris D]

Yea it was somewhat condensed. I skipped some of those steps because most people have probably installed XF at least once but I guess that's not always true so worth pointing out

 

[Robust]

This is a good tactic.

My first add-ons were just essentially template modifications. My first add-on that used any sort of JavaScript was probably a year or two later.

Definitely a good tactic. My first was the same. I still haven't needed js in an add-on yet.

Make realistic goals, achieve them, learn a lot.

 

[sbj]

I have a simple question.

Now I created in phpstorm a new project with a test file in a different directory (not where my xf installation is).
But everytime I run the testfile, my browser (firefox) points to the locally installed xf installation.
How can I make phpstorm to run the testfile, and not the other projectfile with the xf installation?

Btw.

@SneakyDave helped me out to install xdebug for debugging on phpstorm. Thank you very much.

 

[Xon]

Following from Xon, in modern frameworks (hopefully XenForo 2) queries aren't done much manually. For example, all my apps in Laravel I don't think I've wrote one raw SQL query.

While the syntax that @Chris D and others has show is welcome, this doesn't stop people from writing poorly designed queries. Or writing a query which works well at small scale but falls apart at a large scale.

It may make it harder todo so, but it will still happen.

The classical example is the 'n+1 query' problem.

Fetching a list of posts and then in a foreach fetching each post's thread as it is used is bad. It doesn't scale well at all. XF's database code can't see the relation between the list of posts and list of threads. The code needs to know to bulk fetch unique threads after getting the posts, and then foreach over the posts using the already fetched thread.