Add-on Install & Upgrade

Add-on Install & Upgrade 1.4.3

No permission to download
The "delete installed files" issue is a bit contentious. I did some testing with this and unfortunately you tend to get permissions errors - at least I did in Windows, my test box. Maybe it would work on Linux. Just not tested it yet.
Windows permissions does not make sense, Linux does. If you want a easy way to run a local server on Linux, look at virtualbox. There are plenty of images around for that-
 
urgh! as I said "Automatic" and "Upgrader" words in the same addon's title, I was hoping that it was also do a check versions and automatic download from the RM. :love:

...beside that great addon!

A question, files like "instructions.html" or "readme.txt" are leaved behind, right?
 
urgh! as I said "Automatic" and "Upgrader" words in the same addon's title, I was hoping that it was also do a check versions and automatic download from the RM. :love:

...beside that great addon!

A question, files like "instructions.html" or "readme.txt" are leaved behind, right?
If they're in the upload folder, they'll be copied to the root of your installation. But no add-on developer should leave those files in there. If they're in the zip but not in the upload folder then they'll be ignored.

And good suggestions. They are what I've got in mind already ;)
 
Which add ons are known to work with this upgrader? This is what I have been looking for since I opened my forum.

James
 
The thing that makes the add-on compatible with the upgrader is not the add-on itself, but just the way it is packaged.

Simply, as soon as you open the zip file, as long as there is at least a directory called upload and an XML file it will probably work.

If there is anything else it isn't compatible.

I'm also working with add-on developers to see if they'll have a badge displayed on the add-ons which support this.
 
I know how to FTP but hate having to open it up because an addon was updated.

Thanks for taking the time to work on this. Really hope it becomes a community standard. :)

edit: and hopefully developers add the sticker so it's an easy check.
 
The good news is, there's nothing that can go wrong if you try an add-on that isn't compatible.

The worst that will happen is you'll get an error message. All this happens before any changes are made, so it's completely safe.


Chris great addon.

Please in the next update can make translatable the phrase Choose an add-on in the line 32 in the installation file of the addon.

Thanks.
Thanks - sorry about the hard coded phrase. Will update on next release.
 
I would highly recommend you add something to allow developers to mark their addon as "Addon Installer Compatible", simply detecting folder structure is insufficient as some addons may simply adhere to only part of the folder structure. Could be as simple as adding 'installer_compatible="1"' to the <addon> node in the addon xml.

I appreciate the work you've done on this but I honestly think this implementation should come from XenForo itself in a way that integrates with the Resource Manager, anything less will just lead to fragmentation where only a subset of developers uses your standard and others don't use one at all or use something different.

Edit:

By the way, the reason many systems use FTP is because it practically guarantees you have file permissions to write. Your implementation only works if the apache user has write access to all relevant directories, which in a secure environment it will not. So you might want to consider supporting FTP or detail the fact that it requires write permission :)
 
I would highly recommend you add something to allow developers to mark their addon as "Addon Installer Compatible", simply detecting folder structure is insufficient as some addons may simply adhere to only part of the folder structure. Could be as simple as adding 'installer_compatible="1"' to the <addon> node in the addon xml.
I feel this is unnecessary. Forgetting my Add-on Installer for a moment, I feel it's fundamentally wrong for developers to have differing file structures. There should be standard defined that all of the developers agree to. There's several reasons for that:
  • I envisage that there be one set of installation instructions for all add-ons. Those instructions should be in the official XenForo documentation, and those instructions should be identical for each and every add-on that is released. It should never be the case that a user be presented with different instructions, or different file locations for things.
  • A user should never have to wonder why there isn't an upload folder; should never have to wonder why the XML file is in the library folder; should never have to wonder why the upload folder is one folder level into the zip
  • With a unified set of instructions and a uniform structure to add-ons then it will prevent the confusion that is getting more and more common. I keep having to remind myself in this forum that there's a lot of early adopters, developers and techies here who are comfortable with the concepts. But as time goes on, that will get diluted somewhat with a bigger proportion of newer users, non techies etc. who aren't quite as familiar and comfortable with the concepts as we are. That's why a standard will only serve to benefit us all.
I would invite any developer to justify why their directory structure is better than the one this supports which is supported by most developers already and you have to admit the most simple: Everything that needs to be uploaded is in their relevant directories in the upload folder and everything else is in the root of the zip. I honestly don't see why more developers aren't doing it. It would honestly benefit the community as a whole if there was a standard.
By the way, just to be clear, I'm not saying there shouldn't be other folders. Sure, if you want to include a "sources" folder like ragtek does, or a readme file, or whatever else, then great, why not? But I'm just talking about the core add-on structure. Anything else around it can be whatever you like.
I appreciate the work you've done on this but I honestly think this implementation should come from XenForo itself in a way that integrates with the Resource Manager, anything less will just lead to fragmentation where only a subset of developers uses your standard and others don't use one at all or use something different.
I genuinely couldn't agree more. This should be in the core. Not necessarily what I've written. But XenForo should implement something like this into the core. Then that begs the question, if they did implement something like this into the core, would developers start supporting the standard then? I imagine so. So, why not start now? I'm trying to make everyone's lives easier and if I get fantastic developers like yourself and Robbo on board and many more developers then the fragmentation impact will be less and there'll only be a select few developers who will become the odd ones out for not supporting it.

Again, I have to stress, this all sounds like "do as I say so my add-on works". It's not that at all. I have a development version of this which can recognise most of the different file structures that add-ons use (think I have some code in the current version left over from that, needs tidying up) so I could make this more compatible, but I do think that having no standard defined is a problem in general that should be addressed.

By the way, the reason many systems use FTP is because it practically guarantees you have file permissions to write. Your implementation only works if the apache user has write access to all relevant directories, which in a secure environment it will not. So you might want to consider supporting FTP or detail the fact that it requires write permission :)
I am aware of this being a possibility. I will make it clearer that its compatibility also depends on write permissions - but so far so good. This has been pretty well tested so far and I've only found one box this doesn't work on. It was tested by a few people and on one of their shared hosts, we found the ZipArchive class was failing due to PHP not having zlib enabled. Therefore in terms of feasibility, this is all looking very promising :)

Thanks for taking the time to feedback Naatan. Do you think you would consider releasing your add-ons in this format? For example, TemplateSyntax could be packaged like below (I've not included your files, just the proposed structure).
 

Attachments

I feel this is unnecessary. Forgetting my Add-on Installer for a moment, I feel it's fundamentally wrong for developers to have differing file structures. There should be standard defined that all of the developers agree to.

Oh I agree, but as the browser world shows; us having a standard does not mean everyone will live up to it. And taking a stance by hard coding your directory structure at the cost of usability and potentially corrupted installs from addons that do not abide by the standard is not worth it. I'm not saying you should support other standards, I'm saying you should be able to detect and prevent installs of addons that do not support your standard (completely).

By the way going by what you wrote you yourself are breaking the "standard" XenForo uses, as you are using caps for javascript directories. Which is not a good idea one way or another as it's error-prone.


I genuinely couldn't agree more. This should be in the core. Not necessarily what I've written. But XenForo should implement something like this into the core. Then that begs the question, if they did implement something like this into the core, would developers start supporting the standard then? I imagine so. So, why not start now? I'm trying to make everyone's lives easier and if I get fantastic developers like yourself and Robbo on board and many more developers then the fragmentation impact will be less and there'll only be a select few developers who will become the odd ones out for not supporting it.

Again, I have to stress, this all sounds like "do as I say so my add-on works". It's not that at all. I have a development version of this which can recognise most of the different file structures that add-ons use (think I have some code in the current version left over from that, needs tidying up) so I could make this more compatible, but I do think that having no standard defined is a problem in general that should be addressed.


I think there is a standard, it just hasn't been documented. Potentially a better way of getting people to use the XenForo standards is to document it rather than "force" them into a standard they are unfamiliar with. Again I'm not against you forcing the XenForo standard, I think it's good. You just can't "expect" everyone to simply abide by it.


Thanks for taking the time to feedback Naatan. Do you think you would consider releasing your add-ons in this format? For example, TemplateSyntax could be packaged like below (I've not included your files, just the proposed structure).

If you add support for lowercase js folders I see no reason why I wouldn't.

a few more small suggestions:
  • Rather than advertise with your image (which does feel a lot like advertisement), you could include a precanned phrase like "Supports Automatic Addon Installer", so people don't have to use an image that takes up so much real estate and more importantly people can quickly search through resources or the resource manager in general to see what addons support your installer.
  • Please clean up (organize and add comments) your code and host it on github so other developers can contribute. I like the concept but currently the code is still a bit messy, no doubt because it's essentially still a prototype (hence the 0.1 version).
  • Maybe rename your addon to "Addon Installer" or something short.. no one wants to write out a full sentence when referring to your addon ;)
 
Oh I agree, but as the browser world shows; us having a standard does not mean everyone will live up to it. And taking a stance by hard coding your directory structure at the cost of usability and potentially corrupted installs from addons that do not abide by the standard is not worth it. I'm not saying you should support other standards, I'm saying you should be able to detect and prevent installs of addons that do not support your standard (completely).

By the way going by what you wrote you yourself are breaking the "standard" XenForo uses, as you are using caps for javascript directories. Which is not a good idea one way or another as it's error-prone.
Ah, ok. You might have the wrong end of the stick slightly (but I can see why). There's actually only two requirements for my add-on to work and install an add-on:
  • Add-on XML file in the root of the zip file. Can be named whatever you like, as long as it is a valid XenForo add-on XML file.
  • An upload directory in the root of the zip file.
The contents of the upload directory do not matter. You can have as much or as little as you want in the upload folder and in any format you like, though of course it should be compatible with XenForo so usually it would contain at least a library folder containing your add-on's PHP. If you include a lowercase folder in the js folder or an uppercase folder, that's fine, it will still work. I think I will amend my add-on description.
With that in mind, there should never be the chance of a corrupted install. If the XML file can't be found and the upload directory can't be found then the process is cancelled and an appropriate error is displayed.


I've ran out of time, so I'll respond to the rest of your comments later. Thanks again for the feedback.
 
If you are trying to enforce a standard I suggest you talk to other developers to agree on one. I do not agree with this standard how it is with the javascript having capitals in it. I also don't think a standard is easily going to happen.

I have had many discussions about this sort of thing with Naatan. We both agree that it isn't worth the effort needed for standards to properly happen. Would be awesome if they did though!
 
There is no requirement for the JavaScript to have capitals in. My original post is misleading. There is no requirement beyond the upload folder and XML being in the root of the zip.

Will respond in more detail later.
 
Just to continue what we discussed yesterday.

Once again, to be clear, the only requirements are:
  • The root of the zip file must contain a valid, normal, XML install file.
  • The root of the zip file must contain an upload folder.
  • The upload folder can contain anything. Its contents will be copied to the root of the XenForo install.
With that in mind, does that make it easier for you guys to support this "standard"?
Additionally, to confirm what I mentioned yesterday: If neither of the above prerequisites are met, then the install doesn't happen. Therefore there's no chance of corrupted installs. I do need to make my error messages more detailed, but at the moment attempting to install an add-on that doesn't support the "standard" will generate a simple error with no changes made to the system.
I think there is a standard, it just hasn't been documented. Potentially a better way of getting people to use the XenForo standards is to document it rather than "force" them into a standard they are unfamiliar with. Again I'm not against you forcing the XenForo standard, I think it's good. You just can't "expect" everyone to simply abide by it.
Do you think I should write a guide for the Resource Manager? Just a brief, details of the directory structure, and what is benefits are? We could then, as developers, use that Resource thread as a place to discuss this and maybe solidify it further?
  • Rather than advertise with your image (which does feel a lot like advertisement), you could include a precanned phrase like "Supports Automatic Addon Installer", so people don't have to use an image that takes up so much real estate and more importantly people can quickly search through resources or the resource manager in general to see what addons support your installer.
I like this idea. I may very well drop the image.
  • Please clean up (organize and add comments) your code and host it on github so other developers can contribute. I like the concept but currently the code is still a bit messy, no doubt because it's essentially still a prototype (hence the 0.1 version).]
I'm just finishing a pretty big project, then I'm moving home on Saturday then I have to start another big project. I will crowbar some time to improve this. Part of the code needs to be re-written anyway.
  • Maybe rename your addon to "Addon Installer" or something short.. no one wants to write out a full sentence when referring to your addon ;)

Already done. I updated the original resource to reflect the simpler name. :)


So - if I document what I would like to become a "standard" maybe I can look forward to you and Robbo being one of the first posts saying you support this? Although I can't force people to support it, and I wouldn't want to, I think people will want to support it once they understand the problem and realise the benefits of the solution.
 
Just to continue what we discussed yesterday.

Once again, to be clear, the only requirements are:
  • The root of the zip file must contain a valid, normal, XML install file.
  • The root of the zip file must contain an upload folder.
  • The upload folder can contain anything. Its contents will be copied to the root of the XenForo install.

Then I'm confused why you are writing about a standard at all, as you seem to enforce none?

Do you think I should write a guide for the Resource Manager? Just a brief, details of the directory structure, and what is benefits are? We could then, as developers, use that Resource thread as a place to discuss this and maybe solidify it further?
I like this idea. I may very well drop the image.

Not a guide for the resource manager, but rather for the coding standards XenForo follows. I mean if your intend is to get people to use the standard then that's what I'd suggest you do.

So - if I document what I would like to become a "standard" maybe I can look forward to you and Robbo being one of the first posts saying you support this? Although I can't force people to support it, and I wouldn't want to, I think people will want to support it once they understand the problem and realise the benefits of the solution.

Like I said I see no reason why I wouldn't update my addons to have an upload folder, but I won't proclaim to "support" this addon until the code has been cleaned up and it's reached a stable version (ie. 1.x). At the moment it seems to mostly be a prototype and I don't feel it would be responsible for me to advertise it.

I definitely support the idea though, and if you set up a github repo I'll gladly contribute when I have time.
 
Top Bottom