Lack of interest Add On Installation Improvement

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Chris D

XenForo developer
Staff member
Not sure how feasible this is, but I think I might have identified a possible improvement to the add-on installation process.

This idea has come from seeing quite a lot of people get stuck when installing add-ons.

I think sometimes us "techies" take it too much for granted that things are "easy". But it's only easy if you know how and I think what already sets XenForo light years ahead of any other product is already how easy it is to use and customise. Perhaps it could be made even easier.

So here's an idea which I'm going to call RIM (Resource Installation Manager).

The concept is as follows:
  1. User downloads a resource from the Resource Manager. Usually a ZIP file.
  2. User logs in to Admin CP.
  3. User goes to the Resource Installation Manager.
  4. User browses their computer for the ZIP file.
  5. User clicks Install.
  6. Automatic Rebuild.
So the difference here is the user does not need to extract any files, work out where they need to go or find an XML file. The RIM receives the ZIP, unpacks it, moves the files and installs the XML file.
From a technical point of view:
  • There needs to be some sort of way of XenForo or PHP to unpack a ZIP file.
  • There needs to be an absolute concrete standard layout to the ZIP files. Similar to how it is now but strict with no deviation whatsoever. Probably:
Code:
addonID.zip:
| addonID.xml
| upload
      | js
          | addonID
                | youraddon.js
      | library
          | addonID
                | youraddon.php
      | styles
          | addonID
                | youraddon.png
  • A nice to have would be a summary screen before the process starts that details the files that will be uploaded and the add-on title, description and support details.
I can't think of anything else... but I also can't think of much wrong with the idea.
I think it could be a great addition to the core just to make the process of customising XenForo even easier to benefit those who don't find it quite as easy as us :)
 
Upvote 2
This suggestion has been closed. Votes are no longer accepted.
Unfortunately there is no standard for how addon archives are packaged, so there's a lot of exceptions to handle. But it's definitely possible.

I don't want to take on a project like this myself though, simply because it's something the XF dev's likely already have planned for one of their updates, and it really is something that should be supported natively rather than by a third party.
 
I know ;) This is why I have posted it in the Suggestions forum rather than the Add-On Requests forum.


And this would have to be a fundamental change requiring everyone to follow the standard archive packaging format from the release of the feature for their add-ons to remain compatible. The feature wouldn't necessarily support old add-ons (due to the exceptions). The traditional Install Add-Ons feature could be kept for legacy add-ons and power users.
 
well to be honest....

all a dev has to do to make it easy....(mind that making it too easy makes people not learn which takes more of everyone's time in the end.) is to package the addon with the same file tree that xf uses as far as for folders a dev will be including files to...create empty folders representing xf dir structure and keep that as a template folder...then simply copy and paste your addon files to the appropriate folders in the directory tree and zip....a user can simply be told to upload the files to the root of their xf installation and import the xml...


To be quite honest basically it would require much more work from addon developers to change up the format for something that adds absolutely no benefit for the most part.

The idea is good...but to me if you are going to run a forum you have to get your hands at least a little dirty
 
Is there a place or doc where the XF team has laid out a standard for location and installation of add-ons?

At minimum there needs to be instructions which are closer to standard. I have run my site since 1995 and done everything from mysql to htm to php, yet I find the instructions and process confusing. I'd count myself in the top 5% of the general population when it comes to basic tech...

It should be so that anyone who can do the basics (ftp, browse for a file, etc.) should be able to install an add-on with almost no chance of error. It's not like that now.
 
Is there a place or doc where the XF team has laid out a standard for location and installation of add-ons?

At minimum there needs to be instructions which are closer to standard. I have run my site since 1995 and done everything from mysql to htm to php, yet I find the instructions and process confusing. I'd count myself in the top 5% of the general population when it comes to basic tech...

It should be so that anyone who can do the basics (ftp, browse for a file, etc.) should be able to install an add-on with almost no chance of error. It's not like that now.
From looking at the structure of XenForo itself, it should be as simple as placing your add-on in its own parent folder and placing it in the library directory, where XenForo itself runs off from 90% of the time. If you have any JavaScript files, place it in its own folder and put it in the js folder, and images in its own folder and place it in the styles directory. I don't think that's something difficult to do or understand. Written clearly:
  • XenForo root/
    • library/
      • XenForo
      • Your add-on folder/
        • Models, Data writers, que handling, installation, etc.
    • js/
      • Your add-on folder/
        • JS files here
    • styles/
      • Your add-on folder/
        • images
As far as I can tell most–if not all–developers follow the above structure already so being able to upgrade or install an add-on isn't all that much different from doing the same thing with XenForo. It's common to package an add-on in a way that you can just drop it into an FTP program and it will handle the rest (like how XenForo is packaged) by put it in an upload folder.
The only difficulty that may come up is with the less-technically capable, and the mistake usually comes down to uploading to the wrong directory which is easily "fixable". I suppose it will help to have clearer, more user-friendly instructions but otherwise there isn't something that I find problematic or requires a special solution to be developed.
 
It sounds easy enough, but I found it confusing when I first did it and still do in some ways...

Firstly, there are multiple places where certain named directories exist....that is confusing in itself.

Let me try an example. Let's say I want to install Xenmoods.
http://xenforo.com/community/resources/xenmoods.10/
So, I download the Zip and inside it is an upload directory. At first glance, an upload directory would tell me to upload it...but, in XF, this is not true. It is the contents of this which need to be uploaded. Maybe the folder should say "upload_contents". But that is a small item.

OK, so I open up the uploads directory to see what is in it....and there are three commonly named directories, styles, js and library.

The instruction say "upload all the files in the upload/ directory into your XenForo base directory (the one with library/ and styles/)."

Files? Hmm.....that folder contains folders (directories) - so the instructions start as confusing in the first step IMHO. Why doesn't it say to upload the three directories in that directory..and give their names?

Let's say I pass that point - I am supposed to upload them to the base directory:
"(the one with library/ and styles/)"
In my case, that directory already has directories in it with the same name! So I would stop right there. Maybe my base directory has some extra files in it????

My guess is that the author means to upload the enclosed directories into their same named parent directories???
Example, in Xenmoods, load library/Xenmoods into the community/library file and so on?

Are you guys certain you cannot see the confusion in that? Or the danger (uploading directories which replace the existing ones by accident?)

Maybe I'm off-base here, but I think if you asked "normal" people you'd find it is clear as mud.
 
Here's an additional idea: Have the resource system tie into each site's adminCP like Wordpress does. Want to install an add-on? Search for it on your own backend and the system automatically downloads and installs the add-on. Then the system runs a regular cron that checks for updates.

Then you have no manual downloads, no manual updates, developers get real installation numbers, and add-on usage explodes, which leads to better add-ons and more revenue for developers.

The Wordpress model is the best of any system out there.
 
It sounds easy enough, but I found it confusing when I first did it and still do in some ways...

Firstly, there are multiple places where certain named directories exist....that is confusing in itself.

Let me try an example. Let's say I want to install Xenmoods.
http://xenforo.com/community/resources/xenmoods.10/
So, I download the Zip and inside it is an upload directory. At first glance, an upload directory would tell me to upload it...but, in XF, this is not true. It is the contents of this which need to be uploaded.
Maybe I'm off-base here, but I think if you asked "normal" people you'd find it is clear as mud.

I fully agree.
I'm finding that there isn't a standard.

@Onimua. When I open mod files, some of several sub folders, some do not, especially this particular mood mod. So where does the "dark" folder go?

And some say, "forum root" but in actually that means the library which if I'm seeing the structure correctly, this is wrong.

I'm really frustrated right now with this. :)
 
Here's an additional idea: Have the resource system tie into each site's adminCP like Wordpress does. Want to install an add-on? Search for it on your own backend and the system automatically downloads and installs the add-on. Then the system runs a regular cron that checks for updates.

Then you have no manual downloads, no manual updates, developers get real installation numbers, and add-on usage explodes, which leads to better add-ons and more revenue for developers.

The Wordpress model is the best of any system out there.

Concrete5 does this.
 
This is standard practice in Joomla for years. You download an addon zip from joomla extensions site. Then you go to your site's backend and click upload and install which uploads the zip and installs it. :)
 
I know ;) This is why I have posted it in the Suggestions forum rather than the Add-On Requests forum.


And this would have to be a fundamental change requiring everyone to follow the standard archive packaging format from the release of the feature for their add-ons to remain compatible. The feature wouldn't necessarily support old add-ons (due to the exceptions). The traditional Install Add-Ons feature could be kept for legacy add-ons and power users.
that's why i suggested http://xenforo.com/community/threads/suggestion-add-on-package-builder.7248/ :)
 
This may sound dumb but I think add-on names shouldn't start with XEN. I keep almost deleted my forum when I'm trying to delete a mod. Then again, I've been quite the airhead lately. :notworthy::unsure::rolleyes:
 
I like the WP suggestion. If this would seriously be considered, I'd hope there will also be a redesign of the updates of templates, though. At this moment, when installing or updating (or removing) an add-on, I need to shut down the board, and my rebuilding is taking longer and longer.

It would be awesome if that process can somehow be made far less intrusive than it currently is.
 
I flagged this idea directly to the developers.

I just wanted to make sure they saw it, as this Suggestions forum often gets buried with threads about suggestions which either get solved by suggesting an odd on or even resulting in the creation of an add on.

I was acknowledged but obviously it will be a long process for them to even decide whether it's worth doing... but when you see someone whose first experience with the software is it breaking, it makes you think it probably is.
 
Top Bottom