Thoughts On XenForo 2

[digitalpoint]

So XF2 looks pretty good, and has a lot of stuff that I've had to hack onto XF1 (more than I expected, so that's good).

Spoiler: Stuff I won't have to deal with anymore

• Retina graphics support
• Emoji support (in this day and age, I'd even argue you could get rid of the traditional smilies and instead of parsing things like typed smilies into images, convert them into their respective emoji)
• Fontawesome usage for things like editor buttons
• Get rid of image based gradients (haven't looked that close, but it looks like gradients aren't used... network shows no gradient images loading either way). If you must use gradients, use CSS gradients.
• Improved mobile navigation
• Custom thread fields (going to be interesting to see how it handles moving threads between forums with different custom field requirements... this was a pain in the ass in our XF1 implementation).
• CSS transitions/animations
• Payment framework (huge thing for me)
• HTML5 uploader
• Prism based syntax highligher
• AJAX form redirect options if triggered from overlay (what also would be nice is if you could replace an overlay with another overlay as a built-in function like how like how the spam cleaner system works).

Now... things that I've suggested in the past for XenForo, and looks like they are going to be the biggest issues I face with XenForo 2 (most have to do with scaling XenForo beyond single server setups):

• Make a file storage handler - default it to the server file system for things written as files (for example avatars, attachments and sitemaps), but at least abstract it out so it can be changed. This alone makes XenForo not well suited for a multiple web server environment. I have XenForo 1.x addons that move avatars, attachments and sitemaps out of the local file system, and it's an absolute must have for multi-web server setups.
• Don't force InnoDB storage engine when creating tables - Maybe a manual override in the config file (even something like `$config['db']['forceStorageEngine'] = 'ndbcluster';` would be soooo nice)? In my case, I use ndbcluster storage engine for everything, and it's a pain in the ass when you do an upgrade to force all database requests to go through a single DB server so that you can then go and manually change the storage engine after new tables are created. And then switch everything back to being able to hit any database server (my setup consists of 8 web servers, with the database server always being "localhost"... but that doesn't work with InnoDB because InnoDB normally only exists in one physical server.
• Make a setting for how tables are truncated - There is some more info on it here, but it basically would be a toggle between using "TRUNCATE TABLE" and "DELETE FROM". The latter won't hang if a hot backup is going on. A simple singular helper method you pass the table name to would be useful.
• Show hostname in Server Error Log - Tracking down an issue sometimes is related to a specific physical server in a multi-server setup.

 

[MichaelDance]

Looks so much better.

 

[doublespaces]

Hopefully it all get a stable released while I've got all my licenses active

 

[CarpCharacin]

How did you get emojis to work in XF 1?

 

[eva2000]

@digitalpoint definitely would love to see these suggestions added for multi-server setups !

 

[Fred.]

If I understand it correct the File Storage Handler is already there.

Abstracted file system
Instead of writing to semi-hard coded paths, XF2's main file writes now write through an abstracted system. This makes it much simpler to write files out to locations other than a local disk. Commonly, this would involve writing the files to a cloud storage system such as AWS S3, but there are various other potential approaches.

Reading and writing is done through the file system object grabbed from the app ($app->fs()). Here's what a path might look like:
Code:
internal-data://attachments/0/123-abcdef0123456789abcdef0123456789.data
This would identify the internal-data as the "mount" and the rest would represent any subsequent path and file name. The specific adapter would represent these as is appropriate for their usage.

The available mounts are:

• internal-data -- for data that is only accessible via PHP. By default, this is still the local internal_data directory.
• data -- data that is accessible via PHP and directly via a browser.
• code-cache -- this is specifically for generated PHP code that we then write out to files. By default this is within the internal_data directory. This is distinguished from regular internal data files because we will be including/requiring files via the specified path so that we can take advantage of opcode caching. You want accessing these to be fast.
• temp -- just for temporary files. This always resolves to a local temporary directory. This isn't used commonly but it can help transition from a potentially remote file to a file that is known to be locally accessible (as some processes require local files).

https://xf2demo.xenforo.com/threads/whats-new-for-developers-in-xenforo-2-part-2.1409/

 

[digitalpoint]

If I understand it correct the File Storage Handler is already there.


https://xf2demo.xenforo.com/threads/whats-new-for-developers-in-xenforo-2-part-2.1409/

Yep... exactly what I was hoping for. Santa loves me. Hah

 

[Slavik]

Yep... exactly what I was hoping for. Santa loves me. Hah

We told you, those pictures of Mike were not to be discussed!