I developed my extension for Thunderbird, which is officially approved at https://addons.mozilla.org
I want to implement my custom update mechanism, in case this extension is blocked in the Mozilla repository.
I used this manual and implemented everything strictly according to the instructions - https://developer.mozilla.org/en-US/Add-ons/Updates
I check updates in Thunderbird, the request is [HTTP / 2.0 200 OK 114ms], but the version is not updated and no action is taken.
In tundberbird, I have version 1.0.3 and in the updater.json 1.0.4
I view console and see error: Update manifest property 'strict_min_version' has incorrect type
I change field from: "strict_min_version": 50 to "strict_min_version":"50.0" and update fine work!
Related
I took over a website for my client and I tried adding an extension to Typo3. When I did, the whole website crashed and displays a HTTP ERROR 500. I found this thread with a similar problem, followed the instructions and erased the key that was supposed to be removed typo3 site offline after extension upload but that didn't work.
I gained access to the cPanel since I couldn't access the backend login page. So now i'm able to access all of the root files and hopefully fix the problem. Does anyone know anything to fix it?
You should read the error log (for the PHP service or Apache, depending on how your hosting works). There you can see the actual error message which then can give you an indication what's actually wrong.
The most common reasons are:
Extension version is not compatible with the version of TYPO3 you used (and you ignored the warning when installing).
Extension is written in a way that it assumes you update the database schema, which may not happen automatically when you install the extension.
Extension calls on classes that must be loaded and does not provide class loading for the installation you use (e.g. some extensions only offer composer support and won't work if you install without composer).
Extension uses PHP modules that are not installed or is incompatible with the version of PHP that is used.
You should be able to recover this by using the TYPO3 install tool to manually update the database schema and perform checks that the extension works (TYPO3 8.7+ only). If that does not help we will need additional information:
Which TYPO3 version do you use?
Was it installed with composer?
What is the exact error message you get in PHP error logs?
If the extension you installed is public, a link to it would help determine why you get the error.
Hope this helps!
We have been using the Grails Facebook-graph plugin for a while now - it has been working perfectly until earlier this month when FB apparently turned off their old authentication scheme, and indirectly forced everybody to use oauth2 instead.
This post from FB https://developers.facebook.com/blog/post/525/ describes the changes, and the issue in the Grails plugin seems to be that it does not comply with the new standard.
The main issue appears to be in the way the active user data is being maintained in the plugin. This is currently based on the FB provided cookie "fbs", which contains all the necessary session data related to the active user. Unfortunately, this is no longer provided by FB (apparently replaced by a "fbsr" cookie instead).
I have searched the FB documentation, and in various forums for details on how to upgrade the plugin, but unfortunately without luck.
Can anyone help with a hint or two on what steps should be performed in order to get the plugin updated?
EDIT: I think the updated version of the plugin (0.14) has been pushed the public repository. You should try grabbing that one first before reading the rest of my answer.
It looks like the plugin maintainer, Jesus Lanchas, made some updates over the last few days to enable oauth2 support. It has not been pushed to the plugin repository yet, but I was able to get it working with my project. Here's what I did:
#Install a local copy of the plugin WITHIN my project
mkdir plugins-local
cd plugins-local
git clone git://github.com/chechu/grails-facebook-graph.git
mv grails-facebook-graph facebook-graph
Update BuildConfig.groovy and tell grails where to load the plugin from. I put this line before grails.project.dependency.resolution
grails.plugin.location.'facebook-graph' = "plugins-local/facebook-graph"
Uninstall the existing facebook-graph plugin from my project
grails uninstall-plugin facebook graph
This is a temporary solution for me until the offical update hits the repo, but it allows me to make sure I'm using the same new code everywhere.
EDIT: we released our Facebook Grails SDK on GitHub :
https://github.com/benorama/facebook-grails-sdk.
Currently only tested on Grails 2.0…
Any feedback is welcome before we release it officially to Grails.org.
Indeed, it looks like Grails Facebook-graph plugin does not support OAuth2 Facebook authentication (which is required since October 1st 2011).
We have already ported the official PHP SDK V3.1.1 to ColdFusion 9 (https://github.com/affinitiz/facebook-cf-sdk).
Last month, we started to implement it as a plugin in Grails 2.0.
It is currently at an alpha stage so we have not released it yet, but it is working on our prototype.
To connect to the Facebook Graph API, it uses RestFB internally.
If you want to give it a try and give us some feedbacks, let me know, I'll sent it to you by email.
When we push a new version to our server, the old extensions deployed take some time (<7hours in the docs, but I have seen more) to update themselves. The problem is that these OLD extensions may talk to the NEW services/api deployed on the server, thus raising conflicts. And those are very hard to hunt down...
Any advice?
Thanks.
You can't force autoupdate but you can pass api version along with the server response and have extension notify users to upgrade if it is outdated (response version doesn't match hardcoded into extension version).
UPDATE
Ok I just reread the question and looks like author is talking about the extension gallery. In this case you can't just point a user to the gallery as it doesn't allow you to reinstall an extension without uninstalling first anymore (it used to a while ago). In this case, to force reinstall you would have to either ask users to hit "Refresh now" button on the their chrome://extensions/ page, or download and install your extension's crx directly, which has the following (scary) format:
http://clients2.google.com/service/update2/crx?response=redirect&x=id%3D<EXTENSION_ID_HERE>%26uc%26lang%3Den-US&prod=chrome
I would be very happy to have "mailtogroup" installed - really - so if someone could tell me how to exactly configure "mailtogroup" in order to sent group email. The problem is that no group names pop up, when I do the search. I was able to setup the single user email facility.
The first thing I'd check if you have the right version of UberSelectionWidget installed. From the documentation for mailtogroup:
This content rule uses the UberMultiSelectionWidget from plone.app.form. This widget is
broken in version 1.1.7 of plone.app.form. Plone 3.3.4 has this version.
As of version 1.1.8 the widget is working again. To use the correct version pin down
plone.app.form:
[versions] ... plone.app.form = 1.1.8
Do you see any errors in the Plone log? You need to be precise when searching for users/groups. Can you try to search for the default 'administrators' group? Are you using the latest version (1.2) of mailtogroup?
Where can I find information about upgrading Magento Enterprise 1.7. to the latest 1.9. ?
There's no such documentation.
Your general approach:
1. Close production server
2. Backup all DBs and Magento installation
3. Turn off all your custom extensions and themes
4. Delete from HDD: core Magento modules, their layouts, all standard themes and cache.
5. Get 1.9 EE, copy it over your installation
6. Request Magento through http
7. Walk at your site, notice errors and warnings, fix them
8. Check documentation and update for your theme, whether it supports EE 1.9. Turn it on if it supports, otherwise you'll need another theme.
9. Check documentation and updates for all your custom extensions - whether they support 1.9. Turn them on - one by one.
You won't have any problem with upgrading all core DB data - it's made automatically.
You'll have problems with your custom theme, as you'll need new version with support for 1.9. And you'll need to check your custom extensions and upgrade their source and DB data to fit 1.9.
Generally all Magento upgrades work by running the updated code with the old database. The differences will be detected and incorporated automatically on the next page request. Magento keeps track of every module's version number for this reason.
Because there is a chance some modification will break it is best to do this on a new (temporary) site then add the modifications back in gradually. That way the old site is still active and uninterrupted.
I think there is no official documentation. The best way is to figure out what core functionality is used in your customizations and after that look at theirs realization in new version: does it changed or not.
To know what was changed in new version you could check changeslist