This is not coming from Joomla core, but from a 3rd party (likely custom developed) component that exist in your site.
First see if you really need/use this component, or you can simply uninstall it. If you need it, then look for any information you can gather for this component - find the developer and his site/email and ask if there is an update for ...
When you have multiple update servers, you can set a different priority for each. so you can control the order in which the update servers are checked.
If the first one is available, it won't bother checking the rest
Reference Book - Learning Joomla! 3 Extension Development
If I'm not mistaken, moving changes from your localhost/dev-environment to the live site should be pretty straight forward.
Before doing anything, keep a backup of your site live.
As I'm sure you're aware, all settings (apart from the global config) are stored in the database, so if you've made any HTML changes, simply copy all the directories (...
You have to add a client element in your updater xml:
Joomla seems to take the admin as the default.
I tried out your xml and found that joomla was indeed finding the xml file ok and even inserting a record into the #__updates table. However because your module is a site module and the update xml didn't have the client ...
I haven't try it myself. It's a recent discovery of mine in JED, it is called StageIt and it looks promising. StageIt claims it is the ideal staging environment solution for Joomla, making the headache of site updates and development workflow go away.
This taken from the extension's description in JED.
Have a look at the Weblinks repo
It does exactly what you want to do.
The updateserver points to the manifest hosted on that repo.
Download packages are served from the repo as well.
Of course you need to manually update the manifest file with each release.
I recommend you to use this plugin:
it will reintroduce the deprecated DS constant to ease the migration for 2.5.x sites whose extensions still use DS until they get fixed by its developers.
For advanced website staging, you could look into Akeeba UNiTE:
UNiTE is an automated, unattended backup archive restoration tool. It
is software written in PHP, designed to restore and customise Joomla!
and WordPress websites from ZIP, JPA and JPS files created primarily
with the Akeeba Backup or Akeeba Solo software suite. It's main
mission is ...
There is no simple way. This is roughly how I would proceed:
1: Make a full backup of your existing website
2: Install it locally
3: Identify all modifications to your community builder extension by comparing it to a fresh 1.9.1
4: Update community builder
5: Apply all modifications again. Probably you can't apply them 1:1
6: Replace your online ...
I would update your source .xml and .php with your changes and make sure you have method=upgrade in the line like this example. and change your <version>to a higher number.
<extension version="3.9" type="plugin" group="content" >
<extension version="3.9" type="plugin" group="content" method="...
You can develop a Joomla plugin in the 'installer' group.
In this plugin user the Joomla event onInstallerBeforePackageDownload to modify the url of the request made to your server by the Joomla Update request and pass a key or other identification you may use to authorize the download.
Here is below an example of a component 'ABC' that uses an update server....
Yes, you can put the update.xml in the main repository.
As for the link to provide JED, you'll need to open the file on Github, then click "Raw", so you URL will look something like this:
And also be sure to reference this URL in your extension's XML file too.
Found the cause.
I'm using a third party tool to manage, upgrade and monitor my Joomla sites. One of the features is to scan the site for available updates, during this process the update sites are all enabled. The developer confirmed this was the expected behaviour of the product.
I'm able to disable this feature and my updates sites now remain disabled.
I feel so silly...I just forgot to change the version of the component in the XML mainfest file from 1.9 to 1.9.1. If you are running into the same trouble don't forget to change the version of your component in your component's mainfest XML file.
I had this:
In case joomla, extensions are uploaded into the clients site. From JED client site is redirected. So don't need to upload extension in above way. Just upload it in your website and share that link for download.
I've found out that (after the error.log was rendered correctly) my updateserver hoster blocks these connections:
[Wed Apr 29 10:44:49.949248 2020] [:error] [pid 2849] [client **IP**:48884] [client ***IP***] ModSecurity: Access denied with code 510 (phase 2). Matched phrase "Joomla" at REQUEST_HEADERS:User-Agent. [file "/etc/modsecurity/01_hs/bad-user-...
I first came across white screen when updating php from 5.6 to 7.0+. Pre 3.0 installations usually triggered the white screen but some later versions can trigger it too.
Definitely uninstall any components, modules, templates or plugins that are no longer in use. This is just good practice anyhow but saves time updating them when they are no longer ...
I found the issue, it seems that a bug in the joomla updater was fixed some time ago. So the important part was the <type> tag.
The working XML:
<description>SchuWeb Sitemap - Sitemap Generator for Joomla!</description>
If you add the attribute method="upgrade" to the tag extension, your plugin can be installed without uninstalling an earlier version. All existing files will be overwritten, but old files will not be deleted. So you do not need two versions - one for updating and one for new installation!
If you ...
Check if the system has free space.
Check in System / Global Configuration / Server Tab / Path to Temp
Folder if you have a full path (not relative one) to the tmp folder
of your website.
Check in System / Global Configuration / System Tab / Path to
LogFolder if you have a full path (not relative one) to the logs
folder of your website.
Check in System / ...
OK, found the issue and solution, but not the cause!
I went to the thread On RegularLabs' site - https://www.regularlabs.com/forum/exten ... ions#83452. In this, Peter talks about "some" server setting (he doesn't know which - or didn't at the time of writing) changing the case of the Header names. Because Joomla is looking case-sensitive, the installs ...
Well, sorry to ask, but finally got it working like this
<?xml version="1.0" encoding="UTF-8"?>
<element>String written in the "element" field of the #__extensions table for this extension ...
That got me on the right track. It's a little non-intuitive that you can't use extension for package. Here's what I ended up with that works.
First, the package manfiest
<server type="collection" priority="1" name="Connect Daily Update Site">http://www.connectdaily.com/joomla/updates/package.xml</server>
I'll take a wild guess before you reply to my comment above. In your extension's update XML file, perhaps you have set the type attribute incorrectly for the update server. As it's a package you wish to update, the type needs to be set to collection:
<server type="collection" priority="1" name="My Extension Name">http://...