Recently, I wrote a cross-browser plugin using Firebreath, and I made one installer for all browsers. I searched in stackoverflow for automatic plugin installation, and find a bunch of good answers,
FireBreath plugin automatic installation
Deploying a Firebreath plugin on a webpage without manual installation
Plugin Installation
Deployment of NPAPI plugin with minimal user steps
All answers points out that it needs users’ interaction to download and install the plugin.
My question is that does plugin upgrade follow the same process of first installation, which let users to download the latest installer and install it manually again? Is there any other options to make the plugin upgrade more automatically (less user interaction)?
I also searched this answer a little bit relevant, but it doesn’t tell the way to upgrade a plugin automatically.
firebreath plugin refresh after update
Or I should ask what is the best practice to upgrade firebreath plugin?
Basically there is no good answer to your question, unfortunately. I have had in-place updates working for all browsers (updating in the browser without a restart), but it's fraught with difficulty and extremely fragile. I don't really recommend it.
Probably the cleanest update experience I've seen is by using Google Omaha to do the install and automatic updates in the background. The biggest downside to Omaha is that it's a beast to get set up and working; even just building it requires a lot of work, and then you have to customize a lot of constants and such.
The way I do it is just require that the user download and install an update (MSI or .DMG w/ applescript, depending on the platform) and then just tell them they'll have to restart their browser to get the new version. It's not clean, but it drastically reduces the support requirements.
Related
I am following the following blog to configure my golang environment (OS-X machine):
http://webapp.org.ua/dev/intellij-idea-and-go-plugin/
But, whenever I try to add go sdk (installed at /usr/local/go), it appear blank selection for the SDK.
Please suggest me, if I am missing something.
This page lists the SDKs which have already been configured in IntelliJ IDEA. You need to press the "Configure..." button and point the plugin to your SDK installation. Once you do this, it will become available in the SDK list for new project creation.
I would suggest to use the following for writing golang application:
https://groups.google.com/forum/#!msg/golang-nuts/tuGS99f-kqk/Tl5KqNG0js0J
https://github.com/visualfc/liteide
If you want to use IDEA with golang, we've made a lot of progress in the past months. Please install the latest release from github releases and give it a try.
As the name suggests, there are a few issues here and there but it should work much better that the current release of the plugin.
You'll find it a class over the other offerings for writing go apps ;) (disclaimer I'm one of the contributors to the plugin, I'm very biased)
This is a project I've been working on off and on for months and I feel like I'm pretty close, but I just can't seem to get past the final hurdle.
The goal is to develop an organization extension library that contains both internal and 3rd party code that we frequently rely on.
History
As a test project, I started with Apache Poi because that is already in wide use in our environment. I have a plug-in and feature built just from the Poi .jars that allows me to build our current Poi applications as long as I add the plug-in (from my workspace) to my build path. The apps work on the servers because we have already distributed the Poi .jars by manually copying them.
The next step is taking that plug-in and getting it into an updatesite so that all of the servers and developers can synchronize on one version. I found and followed these two excellent blog articles (that I wish existed when I started this project):
http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/
http://www.dalsgaard-data.eu/blog/deploy-an-eclipse-update-site-to-ibm-domino-and-ibm-domino-designer/
With the caveat that the articles are written for Domino 9 and we are running 8.5.3 here, but that only matters in the last (installation) step.
Current
This brings us to the problem. All of the above seems to have worked great up to a point. I can install my feature to my designer client from the eclipse update site and it works great. However, the install is failing when I import that into our updatesite.nsf database. This means that while the developers can all install from the updatesite if I put it on a network drive, that doesn't deploy updates to our servers.
The problem is that when I try to install from the .nsf update site, the Eclipse Updater just hangs. I've let it go for well over an hour and eventually Notes becomes completely unresponsive.
So the question is, is there anything I might have done wrong, either in the development of the plug-in or server configuration that might be causing this issue?
Additional Info
I'm looking at the osgi console and that is largely unhelpful. I am getting the following errors as I'm trying to install: SEVERE Could not access digest on the site: no protocol: 0/5B004DDD5E38F3FF85257CAF004C72C7/$file/digest.zip ::class.method=unknown ::thread=Worker-7 ::loggername=org.eclipse.update.core
I could generate dumps if that would be useful.
Security is also locked down fairly tight here. It could be a security issue - is there a way to troubleshoot that? Once I get to the hang I'm just stuck guessing.
This has been edited for clarity and to update information
I know that this is post is over 5 years ago but...
for those that find this and are trying to resolve the error
SEVERE Could not access digest on the site: no protocol: "
is due to the update site project not having the URL of the Domino updatesite.nsf not being added to the Archives tab of the site.xml.
I found the updatesite.nsf also needs to be anonymously accessible as no credentials are prompted/passed through to the Domino server hosting the updatesite.nsf database (at least from DDE), YMMV from eclipse. So if Anonymous connections are blocked on the Domino server you will be out of luck.
To develop a plug-in you really want to have 3 projects:
the plug-in
the feature
the update site
Of course a feature can contain more than one plug-in (and probably should) and a update site can contain more than one feature (and probably should). Once you have an update site project it features a handy button "build all" that makes sure plug-in, feature and update-site get compiled in one go. And that button is what you really want.
You can point using a setting in your Domino Designer (or local Domino server) to the feature directory. Add a plain text .link file to framework/rcp/eclipse/links, that contains the path to your install site - it then picks up the features and plug-ins from there. After a build you would need to restart designer/server to activate the updated feature.
For the Domino server the approach using an updatesite.nsf and the respective notes.ini setting makes the most sense (to me). http restart required. Lazy people script the whole thing.
I still don't have a great answer for this, but I believe the issue is related to the environment here. I don't have the authority to change the environment, even if I were able to conclusively demonstrate it is the cause of this problem, so it is a moot point. All I can say is that at least one administrator computer had no issue installing from the update site.
For me, the solution for distributing the update site is to put it on a network drive and have everyone install it from there. The server has no problem using it from the updatesite.nsf.
So I've been messing around with the packaging feature that NetBeans offers, following this tutorial: http://platform.netbeans.org/tutorials/nbm-nbi.html. I didn't like how I had to modify the platform that my IDE was running on in order to customize the installer itself, so I decided to create a copy and just change the platform the application suite was using (Properties->Libraries).
This seemed to work fine, and even packaged that platform as part of the installer. However, when doing the packaging itself, I noticed that it was calling the IDE's platform build script to create the installer rather than the one I had customized. This defeats the purpose, at least in my case, of having the separate platform.
Within the platform manager, under the harness tab, I made sure that the platforms harness was being used rather than the IDE's, but it didn't seem to make a difference.
I verified the behaviour by throwing an echo into both the default IDE platform and my customized platform to see which was being called. I also noticed that the Ant call that gets made at the start of packaging makes an explicit reference to the IDE platform, as well.
I've tried this under 7.2 (currently using 7.3) as 7.3 has had some fairly nasty bugs and thought perhaps it was just recently introduced.
At this point I'm thinking it's a bug, but I was hoping that perhaps someone else had come across this and found some sort of solution or could shed some light on why it's doing what it's doing.
Thanks!
This is slated to be fixed for 7.4, in case anyone comes across it in the meantime.
Here's a link to the bug ticket: https://netbeans.org/bugzilla/show_bug.cgi?id=229478
I'm hoping someone can confirm whether or not the following scenario is an issue with deploying updates to WordPress sites and, if so, do you have a solution on how to best manage this?
The basics:
I have a local development WordPress Multisite project for which I
use GIT and Capistrano to deploy to remote staging and production
servers.
Everything EXCEPT the uploads and blogs.dir directories (in
wp-content) are under version control. Yes, the WordPress core,
themes, plugins, etc are updated locally, committed, pushed and
deployed. This means that I have to login and activate plugins
initially - they are simply installed via the Capistrano deploy
The databases on development, staging and production are different and
I'm not concerned about trying to sync these up
My Concern:
Many updates to plugins and the WordPress core also perform updates to the database when doing an auto update via the admin. I am updating WordPress core and plugins locally on my development install. The code to these updates ends up being committed, pushed and deployed. However, when the code is deployed it is simply adding/deleting/replacing changed files to the staging and production servers. Production and staging are missing any of the updates to the database since this is usually part of the auto update process - eg, deactivate, updated, activate (run any updates to database).
My Questions:
Is my concern about the production and staging servers having the
latest code but missing any database updates required for the latest
code accurate?
If so, does anyone have thoughts on how I can modify Capistrano
deploy code to deactivate/reactivate of plugins? What about changes
in WordPress, eg, 3.2 to 3.3?
If Capistrano isn't the tool for this - and I need to do it more
"manually" by logging into the admin - is there a maintenance mode
tool/plugin that will somewhat automate the deactivation/activation of the
plugins so any updates upon activation are triggered?
Many Thanks,
Matt
Its important to note that you don't need to activate and deactivate plugins when you upgrading the WordPress core from version to version. Here is an explanation from Ryan Boren on why. Depending on the plugin though, some of them may have an upgrade process built into their upgrade - that is, the upgrade of the plugin, not of WordPress. None the less I'll go through your three questions and answer them as directly as i can.
1. Is my concern about the production and staging servers having the latest code but missing any database updates required for the latest code accurate?
Yes, when updating, if there is a change to the database schema, then WordPress will not function properly unless the new schema exists. When attempting to access the admin side of WordPress, if the db version is lower than your WordPress version expects, it will redirect you to a database upgrade page.
WordPress sets a global called $wp_db_version in the /wp-includes/version.php file and maintains each of the migration scripts to upgrade the database incrementally from each previous versions to the next until the version number is up to date, seen here. Here is a simpler list in a FAQ showing how the revision numbers correlate to WordPress versions..
2. If so, does anyone have thoughts on how I can modify Capistrano deploy code to deactivate/reactivate of plugins?
As I said above, you dont typically need to activate/deactivate plugins after core upgrades, unless I suppose the plugin specifically requires that you do so. If the schema changes in WordPress break a plugin, then the plugin developers will need to release a new version. When upgrading that plugin, it will be shut off and restarted, and its those developers responsibility to make sure everything that needs to take place does so.
However you may need to deactivate/activate separately in deployed environments such as yours, since the actual upgrade process is taking place on different machine, and thus probably a different database from that which it will ultimately be used on.
Perhaps the best thing to do would be to have your deployment script hit a URI of a plugin within WordPress, a plugin you would write which would deactivate/activate plugins, or an existing one that already does it.
It's possible some exiting plugins might handle parts of what your looking for, but I take the key component of your question to be automation, and an avoidance of having to log into each environment and upgrade plugins for each one, so developing one yourself that does exactly what you need might be the way to go. Developing a plugin is possible if you make use of the tools WordPress already provides.
activate_plugin()
activate_plugins()
deactivate_plugins()
validate_plugin()
Plugin_Upgrader class (maybe)
Look through the whole /wp-admin/includes/plugin.php file to see what you might find useful. Additionally checkout code that actually handles plugins in the admin side in /wp-admin/plugins.php - just to see how its done. You may want to stop the deactivate_plugin hooks from wiping out plugin configuration with plugins that clean-up after themselves, so consider passing $silent as true when de-activating the plugin.
To make this really slick, you'll probably want to grab get_option('active_plugins') to see which plugins were already activated, and only run your script on those (make sure the plugin excludes itself from the process)
3. What about changes in WordPress, eg, 3.2 to 3.3?
Changes from 3.2 to 3.3 should be thought of as no different from any other set of changes, so everything said here applies.
4. If Capistrano isn't the tool for this - and I need to do it more "manually" by logging into the admin - is there a maintenance mode tool/plugin that will somewhat automate the deactivation/activation of the plugins so any updates upon activation are triggered?
I don't think Capistrano will be doing any of the heavy lifting here - but its certainly not in the way either. You should just need to be able to just hit a URI within the plugin, and that should get things rolling within the application. The important thing is that obviously all those functions need to be available so you cant just run it as in independent script.
I've read a lot about IBugTraqProvider interface and implementing an issue tracker into the commit dialog of TortoiseSVN.
IBugTraqProvider is written here.
Is there a more simpler way not to do it, building the plug-in and installing it on TortoiseSVN. The Document is not that clear that a developer can create its own plugin.
I'm working with SalesForce as the Issue Tracker, and retrieved the WSDL file to integrate with the Working Items. Now I need to know how to connect it to TortoiseSVN.
Please any suggestions?
Take a look at issue-tracker-plugins.txt in the contrib directory in the TSVN source code. There's a fairly decent example in C# that should get you heading in the right direction.
When I built a plugin, I built a test harness that passed arbitrary information using the IBugtraqProvider interface, so that I could debug the plugin whilst building it, without having to reinstall the plugin into TSVN each time.