MyBB Community Forums - Developer Tips Thread

I don't have anyone to talk to that cares about anything I like Sad

My friends online and IRL don't understand PHP, much less MyBB forum software. Sometimes when I am just dying to tell someone about a new idea I have had I realize that the person wouldn't care to even hear about it and I wouldn't care to try to explain it :p

The idea for this threads is similar to the Admin Scratchpad thread. In my opinion, that thread has become mostly about the design aspects involved in running a MyBB forum. Post here about your projects and coding for MyBB in general. To be honest, posting about PHP/JS coding in general would be fine with me.

I'll start:

I'm sure it won't be a revelation to any of you pros, but to a n00b with a little over a year of experience with PHP, it took me quite a while to understand what the search for efficiency is all about.

In my opinion, efficiency isn't something you ever stop looking to improve. Every time I am look through source code someone else wrote I am looking for neat tricks they've used to save a little time and every time I am looking through my own source code, I look for things that could be done better.

The thing is, there is a balancing act to maintain and two distinctly different aspects to deal with (in most cases).

In the ACP side efficiency is (of course) still important, but you must keep in mind that taking a bit longer in an ACP function is a great idea if it will save the forum side operations any time at all.

The ACP code will be used by admins and of course we want to write good clean code for them, but none of that affects the forum's users when it comes to how efficient the ACP code has been written.

An example plugin might be a plugin for featuring specific threads and the threads OP that creates a database table and allows admin to add entries (lets say tids) to the db on the ACP side.

The most efficient way would be to simply save the info to the database, but if there is any processing at all on the forum side (perhaps the title of the thread from the tid and a short snippet of the first post, OPs username and formatting info) a smarter move might be to accept the input in ACP, store it in the database and then build a cache of the information with any and all extraneous information or parsing needed that can be done ahead of time.
On the forum side of things, working from the database is obviously necessary from time-to-time and cannot be avoided, but when at all possible, use the cache to save multiple queries.

Also, keep in mind that if you are implementing a repetitive hook (like parse_message_start when on showthread.php) you need only load the cache entry once in the first call. So using a static variable and an isset() conditional will allow your implementation of that hook to work without a query or too much extra cache work either.

Feel free to chime in, as I have stated, I am a rookie at this and still have tons more to learn. Smile

Post here about your programming projects and coding for MyBB in general.
To be honest, posting about PHP/JS coding in general would be fine with me.

Don't know if it's for this thread, as it's mainly design, but it's connected to MyBB plugin creation and is a bit annoying.

3. Use MyBB default classes/design/behaviour as much as possible. For example many plugin authors ignore the $theme['imgdir'] variable, so if they add image and someone has multiple themes and wants to make the image different in each to match the colors, they would need to edit plugin source first. Other people ignore cellspacing/cellpadding variables, don't add class="button" or class="textbox" to inputs, add jQuery scripts without noConflict, use another class for .thead etc.

4. Use the MyBB template system instead of adding HTML to .php as much as possible. I like the Plugin Library solution - adding it to each theme's templates, which is used rarely, but adding it to Global Templates is sufficient in most cases too (however, once again, this ain't good for multiple themes). Another thing which makes life easier for designers and regular admins.

Different concern - languages.

5. At least try to add all the strings to $lang files, it costs a bit time, I know, but you'll save a lot more time for translators and people who want to simply change the text.

Last thing, not connected to coding at all.

6. Use github for providing your plugins. Not only it makes it easier users to download without waiting for approval on mods site, but also for you - the fork/pull request/bug report system can be quite helpful.

When creating interface in ACP, always test in both Default and SharePoint themes Dodgy

(2013-09-25, 04:19 AM)Wildcard Wrote: [ -> ]When creating interface in ACP, always test in both Default and SharePoint themes

We removed Sharepoint in 1.8 Wink

The best tip I can give is read the PHP manual. Heck, you can even download it. I have a local copy of the PHP manual so when I don't have Internet access I can still look at functions or arguments.

(2013-09-25, 04:33 AM)Nathan Malcolm Wrote: [ -> ]We removed Sharepoint in 1.8

Pay me no attention. I use SharePoint all the time and missed a display error because it only showed up in the Default theme :p

Want to easily test regular expressions? Just type your text into a Notepad++ window and use the search & replace feature with the regex option and your chosen expression. Easy peasy.

Haha that gravedig Big Grin

It's way more efficient to code your $lang variables as you make your plugin, rather than going back when you're all done and trying to find every place you typed plaintext.

Also, make sure your install/uninstall/activate/deactivate methods all work right and delete/add the appropriate things to the database, it's real annoying having to fix your db if you mess up the db calls. Much better to get them right first so you don't have to worry about them breaking and screwing you later.

(2016-12-14, 02:47 AM)fizz Wrote: [ -> ]Haha that gravedig

Necro bumping? lol

Here's a tip:

Always write code with extension in mind. For example, recently I developed a fiddle to be used internally by a group of developers. They wanted to optionally include several of their favorite JS libraries. Rather than writing:

if (data.jquery === true) {
	$("#jQueryCheck").prop("checked", true);
}

OR

$("#jqueryCheck").prop("checked", data.jquery === true ? true, false);

...for every library (there were several), write something like this:

$(["jquery", "jqueryui", "prototype", "scriptaculous", "etc", "etc"]).each(function() {
	$("#" + this + "Check").prop("checked", data.[this] === true ? true, false);
}

While it is a little harder to read, it makes extension as easy as adding another name to an array and of course, creating relevant code and elements.

Don't use '', 'NULL', or anything else to represent '0' in database fields of type INT. It will work fine for 95% of the users and the other 5% will make you feel like an idiot. :/