Template version control

[king of the internet]

Many of use Git or another version control system to manage their site. Is there any reason XenForo has to reinvent the wheel here? My #1 problem with XF is that it doesn't store templates in the file system (WebDAV is not acceptable as it does not allow me to version the templates with Git).

It seems as if XF already has this functionality with _writeDevFileOutput but it isn't documented and I have no idea if it will go away or be renamed in a future version.

 

[Jeremy]

For me to version control it, I continually export the .xml and overwrite that. Stores templates, phrases, etc. all in version control.

 

[king of the internet]

For me to version control it, I continually export the .xml and overwrite that. Stores templates, phrases, etc. all in version control.

That is a good idea in the interim, but it is a bit of a pain.

A much better solution is to just store the templates on the file system and have XF detect when they are modified and recompile them. I can use my own editor; I can use my own version control; I can grep or code search in the ways I am accustomed to; etc. The current "best" solution is some hacky mix of using WebDAV for quick edits and manually importing/exporting XML.

This has been brought up a number of times but nobody has officially commented on the situation. This is a big enough deal for me that I am wasting my time trying to edit the XF source code to fix it, which is sad because I paid money to avoid wasting my time with forum-related stuff. I didn't expect this would be so hard when I purchased the software, and honestly I am having regrets, because the whole template situation is broken, front-to-back. Custom file system/version control (guess I won't use Git). Custom HTML syntax (how do I integrate it with the templates the rest of my site uses?). Custom CSS syntax (so much for the best of breed SASS). Just, why? All I want is a forum system. Any and all reinventing the wheel makes my life harder.

 

[Jeremy]

The template system isn't broken and is one of the most powerful things I've ever dealt with.
In terms of your comments:

• Exporting an XML may be annoying, but it allows you to version control everything. I use git in my add-on development and yet to have major problems.
• Custom HTML syntax: If you really want to, you could write an entire skin in straight HTML. The HTML tags (prefixed) allow developers ease of use in areas of difficulty (looping, etc.). If you want to integrate it into your full site, you may want to take a look at the template renderers, they give you a plain HTML parsed version of a template.
• Custom CSS syntax? Are you talking about Style Properties? This makes it easy for non-designers to make changes to their style. Brogan has done most of his style by editing the style properties and not touching CSS. It makes things easier. SASS needs compiled, and is geared towards developers. You can't expect software to compile SASS to be on shared servers, you need to aim for the masses, not the few.

XenForo really hasn't re-invented the wheel on anything. The whole XenForo template system, style system, is one of the best in the industry, if not the best. Your proposed change to the template system would require a complete rewrite of several parts, make life difficult for many, and have minimal benefits.

 

[king of the internet]

I'm sure everything XF has come up with is just peachy, but I own a large site and a large forum and my needs are different than people using shared hosting. I need XF to play nice with industry standards (that is, Git). I don't need XF to use SASS directly, but to give me a well-documented backdoor to use something else than what they've come up with. Same with HTML. In general though I don't wish to debate the merits of the particular HTML/CSS choices XF chose: I just want interoperability with standard tools. They can do whatever they want as long as I can integrate with the rest of my site in a sane fashion.

And right now making up their own version control system does not make it easy to integrate with the VC the rest of my site uses.

 

[AlexT]

I'm sure everything XF has come up with is just peachy, but I own a large site and a large forum and my needs are different than people using shared hosting.

You think everyone who finds xF peachy is using shared hosting?

xF is not the holy grail (nor is any other forum software) and I am sure many of us have particular needs that aren't met by the default xF package. Fortunately, xF leaves a lot of room for extensibility‎.

 

[king of the internet]

You think everyone who finds xF peachy is using shared hosting?

I find XF "very peachy" in many respects, but the Git issue is very important to me. I'm not sure what the point of singling out that one line was, you completely missed the point of my post. King Kovifor brought up shared hosting, not me.

xF is not the holy grail (nor is any other forum software) and I am sure many of us have particular needs that aren't met by the default xF package. Fortunately, xF leaves a lot of room for extensibility‎.

Wanting a seamless experience with industry standard version control tools is not an unusual or unreasonable request. All you have to do is have the templates on the file system. As for "all of us have particular needs", I am making my needs known. It is up to the XF devs to decide whether they want to address them or not, but I *would* like a response from them. In general, I'm not interested in what the rest of you have to say unless you want to develop an add-on that solves my problem, and then I am very interested

 

[AlexT]

I get your point... you would like to use git as a version control system for xF implementation, and you find the current way xF is handling templates less than ideal for that purpose.

But you must understand that your needs are not necessarily the needs of others. When you complain about how xF is making your life more difficult (notice my emphasis on your), you fail to see that much of what xF has to offer today is the direct result of users communicating their needs to the developers.

 

[king of the internet]

But you must understand that your needs are not necessarily the needs of others. When you complain about how xF is making your life more difficult (notice my emphasis on your), you fail to see that much of what xF has to offer today is the direct result of users communicating their needs to the developers.

Yes, and now *I* am communicating *my* needs, because I would like templates on the file system. See the edit to my previous post, which was to respond to an edit you made on your post.

 

[AlexT]

In general, I'm not interested in what the rest of you have to say unless you want to develop an add-on that solves my problem, and then I am very interested

Hint: If you are not interested, stop wasting your time using this forum and use the contact us form instead. I certainly won't waste mine on you any longer.

 

[Arantor]

The key reasons for it being in the database are security and customisability - and they're intertwined.

Let's say, hypothetically, everything's files in the filesystem. User wants to change the template... they have to edit the file - no big deal to us, but to users who find FTP cumbersome, or don't have access to it right now for a small change, having something in the admin panel would be nice.

But if it's writable from the admin panel, that means file permissions must inherently be elevated for the webserver user to be able to write that file. And on most hosting setups, because most of them are not particularly secure, that means everyone else on the server can now also write to that file. This is, unsurprisingly, a security risk. (And one that bites users of other platforms every day without fail because that platform has an automodding feature that applies find/replace changes to files... separate strand of the same problem)

The other approach is that we have the files and track some of the changes in the database - that still leads to problems especially if the file changes and the database content is now inconsistent. Essentially you need to have one or the other only, not a hybrid.

It gets ugly fast

 

[king of the internet]

The key reasons for it being in the database are security and customisability - and they're intertwined.

Let's say, hypothetically, everything's files in the filesystem. User wants to change the template... they have to edit the file - no big deal to us, but to users who find FTP cumbersome, or don't have access to it right now for a small change, having something in the admin panel would be nice.

But if it's writable from the admin panel, that means file permissions must inherently be elevated for the webserver user to be able to write that file. And on most hosting setups, because most of them are not particularly secure, that means everyone else on the server can now also write to that file. This is, unsurprisingly, a security risk. (And one that bites users of other platforms every day without fail because that platform has an automodding feature that applies find/replace changes to files... separate strand of the same problem)

The other approach is that we have the files and track some of the changes in the database - that still leads to problems especially if the file changes and the database content is now inconsistent. Essentially you need to have one or the other only, not a hybrid.

It gets ugly fast

I agree that a hybrid solution is a bad idea. I can't speak to anyone else's setup--but for me, I would probably end up disabling editing templates from the ACP if templates were on the file system. All collaboration goes through Git and GitHub where the changes can be reviewed, and deploy is also done through Git.

I think this solution is *more* secure than through the web. Again, I don't know anything about the shared hosting providers that people bring up (except that I will mention that bill-by-usage VPS in the "cloud" is popular these days, and solves all of these shared hosting issues). But as a thought experiment, I imagine editing the code for the rest of my website through XF's online editor. We'd be giving up standard review tools and bug finding using git bisect. That doesn't pass my smell test.