图片来源：视觉中国

7月22日，京东集团董事局主席兼首席执行官刘强东发文称，“本次假疫苗事件，我强烈建议相关政府部门严惩处理所有责任人，给公众一个交代！我会想政协提案，我会发动我身边的亲人、朋友，我会竭尽我所能，在法律范围内，讨要一个说法！”

“本次假疫苗事件，比那些制造假阿迪、耐克的性质恶劣百倍！这些人不仅应该罚他个倾家荡产，更应该施以重刑！作为一个无比愤怒的父亲，我在此强烈呼吁所有为人父母和即将为人父母的人都行动起来，设身处地想一想，如果你的孩子也被注射了假疫苗，你是何心情？”他在文章中痛斥，“可怜天下父母心！此事必须为那些成千上百万的无辜孩子有个交代！为那些绝望的父母有个说法！还社会一个公平！”

“如果在这样的违背人性底线的事情上，我都不能有所作为，那将是我的无能，我也无颜以对政协委员这四个字，更无颜以对我深爱的孩子们！”刘强东承诺全力讨还公道的同时，还向食药监局表达了感谢，称“这次假疫苗事件是食药监局主动检查发现的”，“他们不发现，会有更多孩子受害！希望食药监部门继续努力！罚他个倾家荡产！”

刘强东的矛头直指长春长生生物科技有限责任公司（002680.SZ）。

7月15日，国家药品监督管理局发布了关于长春长生生物科技有限责任公司违法违规生产冻干人用狂犬病疫苗的通告（2018年第60号），通告指出， 根据线索，国家药品监督管理局组织对长春长生生物科技有限责任公司开展飞行检查，发现该企业冻干人用狂犬病疫苗生产存在记录造假等严重违反《药品生产质量管理规范》行为。

当日，国家药品监督管理局已要求吉林省食品药品监督管理局收回该企业《药品GMP证书》（证书编号：JL20180024），责令停止狂犬疫苗的生产。

次日，长生生物发布公告称，“为了保证用药安全，长春长生正对有效期内所有批次的冻干人用狂犬病疫苗（vero细胞）全部实施召回。”同时，上海疾控发布通知称，已全面停用长春长生生产的狂犬病疫苗。进一步的消息，需等待国家药监部门和疫苗生产企业的后续通知。

根据21世纪经济报道，2017年长生生物将近99%的收入来自疫苗，其中冻干人用狂犬疫苗（Vero细胞）是子公司长春长生的核心产品之一，狂犬病疫苗在2017年的批签发数量达到355万人份，位居国内第二位。长生生物的冻干人用狂犬病疫苗在2012年-2015年一季度，分别实现主营业务收入2460.83万元、846.81万元、21268.41万元和7370.89万元，占公司总营收的比例分比为5.70%、1.91%、34.36%和47.10%。

这是该企业一年内第二次被发现产品生产质量问题。

7月19日晚，长生生物发布公告称，公司全资子公司长春长生生物科技有限责任公司收到吉林省食药监局的行政处罚决定书，因在国家药品专项抽验中，长春长生生产的吸附无细胞百白破联合疫苗在中国食品药品检定研究院的药品抽样检验中被检出效价指标不符合标准规定，应按劣药论处。

据界面新闻此前报道，百白破联合疫苗用于预防百日咳、白喉、破伤风三种疾病，接种对象为3至24个月龄儿童。经查明，长春长生该批药品生产数量共253338支，由吉林省药品检验所抽样552支，销售到山东省疾病预防控制中心252600支。

去年11月3日，原国家食药监总局曾对这次百白破联合疫苗效价指标不合格产品处置情况作出通报。行政处罚决定书认为，长春长生的行为违反了《药品管理法》中“禁止生产、销售劣药”的条款，吉林省食药监局决定没收库存的百白破联合疫苗186支，没收违法所得85.88万元，处违法生产药品货值金额三倍罚款258.40万元，罚没款总计近344.29万元。

除了已经停产的百白破联合疫苗和狂犬疫苗，目前长生生物还拥有另外四个产品，包括冻干水痘减毒活疫苗、冻干甲型肝炎减毒活疫苗、流行性感冒裂解疫苗和ACYW 135群脑膜炎球菌多糖疫苗。

7月20日，长生生物报收14.50元/股，已连续五个跌停，一周内市值蒸发近98亿元。

作者：郑超前

 

在进行升级工作之前，我曾经查阅了很多互联网上的文献，遗憾的是，国内没有一篇完整记录Joomla1.5升级至2.5的技术类文章。想起来还是我的英语帮了我大忙，经过不断的搜索，从Joomla官方网站上找到了Joomla1.5升级为Joomla2.5的权威文章。文章链接如下：http://docs.joomla.org/Migrating_from_Joomla_1.5_to_Joomla_2.5

为了方便不习惯看英文文档的技术ers，我将文章的精髓进行翻译，并补充各种我在实际升级过程中遇到的问题。如果大家要感谢我的话，经常光顾本站的广告链接就好了。

Joomla1.5升级至Joomla2.5神功现在开始！

一、升级之前的准备。

升级开始前，以下准备工作是必须的。

1. 重新判断一下，你的Joomla是否真的要升级？当然，如果你是接单赚钱的话，没有真不真的问题，你肯定要做的。但是如果是你自己的网站，你真的要考虑一下，是否真的有升级的必要？因为升级就肯定存在风险，而且产生很多附带的工作量，对于这两点，你必须做好思想准备。
2. 你的Joomla1.5是不是最新版本？这里的最新是针对Joomla1.5这个大版本号而言的，Joomla1.5的最新版本是1.5.26。如果你的Joomla1.5不是最新版本，则必须要将Joomla1.5升级至最新版本后才可以进行后面的操作。（原因：我们将会使用JUpgrade进行Joomla的升级工作，而JUpgrade支持Joomla1.5.26到Joomla2.5的升级，很多朋友都抱怨JUpgrade不好用，其实是因为自己的Joomla1.5版本不对）。
   经验之谈：至于如何将Joomla1.5升级至最新版本，请看这篇文章：how to update from Joomla! 1.5.x to the latest version（这篇文章也是英文的，但是内容比较简单，如果大家有问题可以随时联系我，我抽时间会将此文章也翻译一下）。
3. 当前的Joomla插件是否支持Joomla2.5？这也是个不大不小的问题。某些在Joomla1.5下面安装的插件在升级后是不支持Joomla2.5的。因此先要对插件的情况进行一下了解。最理想的情况是在升级Joomla之前，现在Joomla1.5的环境下将所有插件都升级到最新版本，之后再进行Joomla的升级。
   经验之谈：在升级过程中，插件方面我是比较幸运的。我没有按照要求对插件进行升级，而是先对Joomla进行了升级，升级后发现，诸如“Acymailing”，“Community Builder”等插件是无法正常使用的。但好在这两个插件都有相关的补救办法，具体方法我再后面还会说明。
4. 你是否更改了Joomla的核心文件？有关“核心文件”的定义并没有确切的界限，简单的说，凡是升级过程中会被新文件覆盖的文件都属于核心文件。这个问题我想大家不要过于纠结，因为从1.5升级至2.5是大版本号的升级，很多核心文件都会被替换，所以如果你确实修改了很多核心文件的话，我建议你还是考虑一下升级的必要性。
5.  你当前使用的Joomla模版和Joomla语言包是否支持Joomla2.5，这个插件的兼容性基本上属于一个问题。还是那句话，既然进行大版本号的升级，就要做好一切准备。

 二、备份、备份、一定要备份

首先还是要说，我的升级之路比较顺利，虽然遇到过问题，但是没有遇到哪些需要重新来过的大问题。但是对于每一个即将进行升级操作的人而言，我还是想各位说一句“一定要备份、备份、在备份”。这里包括数据库和代码的完整备份，如果哪位连怎么备份都不知道的话，我建议您还是不要升级了，您肯定搞不定接下来的事情。

三、开始升级

1. 首先需要下载升级工具jUpgrade。
   地址如下：http://extensions.joomla.org/search?q=jupgrade。话说这个工具真是个神作，这里要特别重复一下，这个工具是绝对好用的，如果你使用的时候有异常，多半情况下是没有按照本文第一部分的要求将Joomla1.5升级至最新版本。
2. 安装jUpgrade。
   安装方法就是Joomla1.5通用扩展安装方法。

    

   • 进入你的Joomla1.5后台，然后依次点击Extensions >> Install/Uninstall。
     
   • Browse >> Select com_jupgrade >> Upload File & Install
     
   • 安装成功
     
3. 启动“Mootools Upgrade ”插件。
   • 进入 Extensions | Plugin Manager
   • 查找 “System – Mootools Upgrade”
   • 将此插件开启
   请确保Mootools Upgrade插件已经正确安装并开启， jUpgrade需要依靠此插件才能正常运行。
4. 对JUpgrade进行设置。
   截止到本文编写时，JUpgrade的版本号是2.5，支持将Joomla从1.5升级至1.7或者2.5，并附带了众多的升级选项设置。具体设置位置在：Administrator > Components > jUpgrade > Parameters.Global

    

   • Distribution – 选择要升级到的Joomla版本号，1.7或是2.5
   • Prefix for old database – 当前Joomla网站的数据库表前缀
   • Prefix for new database – 升级后的Joomla网站的数据库表前缀

   Skips

   • Skip checks – 略过升级前的检测
   • Skip download – 略过下载升级包（注意：当你已经自行下载了升级包，并将升级包放入temp文件夹中，才选择此选项）
   • Skip decompress – 略过解压缩（注意：当你自行下载升级包后，且将升级包放入temp文件夹中，并自行解压缩后，才选择此选项）

   Templates

   • Keep original positions – 保留原始的目录结构

   Debug

   • Enable Debug – 允许错误调试，当升级出现错误的时候，显示相关的错误信息。
   以上信息配置完成后，保存即可。
    
5. 移植开始。
   依次进入：Components >> jUpgrade
   
   开始升级
   
   
   这个时候要注意不要退出页面，直至所有加载条都完成加载后才可以关闭页面。
   
   另一个注意事项，JUpgrade只将Joomla1.5的默认模版进行了升级，因此当你打开升级后的网站时，网站的默认模版是被选中的，需要在后台进行切换才可以。

四、升级之后

1. 首先先要恭喜你经过了这个惊心动魄的过程。话说我在进行升级的过程中，每点击一个按钮时心都提到嗓子眼了，当发现没有报错，又会暗自狂喜一下。
2. JUpgrade的升级过程实际上是非常安全的。JUpgrade在升级网站的时候，没有对原来的Joomla网站进行任何的修改，原来的数据库表、源文件还是在那里，JUpgrade实际是在原来网站的根目录里面创建了一个“jupgrade”文件夹，并将升级后的Joomla2.5网站文件保存在了这个文件夹里面。
3. 依次检查一下下面的这些功能是否还是正常工作：
   • Banners
   • Categories
   • Contacts
   • Content
   • Menus
   • Modules
   • Newsfeeds
   • Users
4. 了解了升级原理，并确认升级成功后，下面就可以对原有网站进行清楚了。清楚地方法也很简单，将数据库中Joomla1.5表前缀的数据表全部清除，并将网站根目录中除了jugrade文件夹的源文件全部删除，然后将jugrade文件夹中的文件转移至网站根目录即可。

五、有关“Acymailing”和“Community Builder”升级后的问题。

这两个插件在Joomla从1.5升级至2.5都出现了问题。问题描述和解决办法如下：

1. Acymailing
   问题描述：升级后Acymailing在Component菜单下直接消失了。
   解决方法：很简单，下载一个最新版的Acymailing插件，然后重新安装即可。可以放心，原来的数据都会保留。
2. Community Builder
   问题描述：升级后点击Community Builder菜单后报错。
   解决方法：也不难，下载一个最新版的CB，解压缩后按照里面的提示对CB进行升级即可，原来的数据库也会保留。

Contents [hide] 1 Turning on "Debug mode" 1.1 [checks] 1.2 [cleanup] 1.3 [download] 1.4 [decompress] 1.5 [install_config] 1.6 [install_db] 1.7 [1] [users] 1.8 [2] [categories] 1.9 [3] [content] 1.10 [4] [menus] 1.11 [5] [modules] 1.12 [6] [banners] 1.13 [7] [contacts] 1.14 [8] [newsfeeds] 1.15 [9] [weblinks] 1.16 [files] 1.17 [10] [extensions] 1.18 [12] [ready] 2 Manually removing a failed migration 3 Tackling specific issues

Turning on "Debug mode"

While every effort has been made to make the migration process smooth and hassle-free, there are some situations where jUpgrade will run into errors or hang during migration with seemingly no indication of progress. For such situations it is recommended to set "Enable migration Debug" to "Yes" in the Parameters screen before running jUpgrade.

A progress log will appear below the migration steps that will update as each step is successfully completed and moved onto the next. This progress log also displays error messages and vital clues that indicate when a problem has occurred mid-step. The following is a quick guide to interpreting the log, and quick resolutions to errors with specific steps.

[checks]

Activity: jUpgrade looking for cURL, set_time_limit and writable /tmp and root folders
Success: denoted by "1"
Fixing at this stage: ensure cURL is installed and folders are writable, "disable set_time_limit" check in Parameters, or "Skip checks" altogether (not recommended)

 

[cleanup]

Activity: jUpgrade running cleanup script, runs when "Delete previous migration" is enabled.
Success: denoted by "1"
Fixing at this stage: ensure folder and database permissions have been granted

 

[download]

Activity: jUpgrade downloading Joomla distribution selected in Parameters screen
Success: denoted by "1"
Fixing at this stage: ensure folder write permissions, working internet connection; for persisting issues download distro package manually, place in /tmp folder and "Skip Download".

 

[decompress]

Activity: jUpgrade extracts contents of distro package into folder labelled after "Target directory"
Success: denoted by "1"
Fixing at this stage: ensure folder write permissions, valid "target directory" label, uncorrupt distro package download; for persisting issues manually extract contents into folder labelled after "target directory" and "Skip Decompress"

 

[install_config]

Activity: jUpgrade updates the "configuration.php" file in the folder of the newly extracted Joomla! 2.5 installation
Success: denoted by "1"
Fixing at this stage: ensure file write permissions, valid "table" and "prefix for new database" Parameter settings

 

[install_db]

Activity: jUpgrade creates the necessary tables for the new Joomla! 2.5 installation in the database
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove tables from previous (failed) migration and try again

 

[1] [users]

Activity: jUpgrade transfers registered user account information and user group mappings
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[2] [categories]

Activity: jUpgrade converts Joomla! 1.5 sections into top-level 2.5 categories and transfers all remaining 1.5 categories (retaining hierarchy) one level below
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[3] [content]

Activity: jUpgrade transfers all articles and converts "frontpage" articles into "featured" ones
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[4] [menus]

Activity: jUpgrade transfers all menus and menu items, updating the ID set to conform with 2.5's new ID numbering policy.
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[5] [modules]

Activity: jUpgrade transfers all standard modules, module parameters and menu item assignments, updating the ID set to conform with 2.5's new ID numbering
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[6] [banners]

Activity: jUpgrade transfers any banners and banner category structures that exist in the Joomla 1.5 site
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[7] [contacts]

Activity: jUpgrade transfers any contacts and contact category structures that exist in the Joomla 1.5 site
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[8] [newsfeeds]

Activity: jUpgrade transfers any newsfeeds and newsfeed category structures that exist in the Joomla 1.5 site
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[9] [weblinks]

Activity: jUpgrade transfers any weblinks and weblink category structures that exist in the Joomla 1.5 site
Success: moving onto the next step
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[files]

Activity: jUpgrade renames Joomla 2.5 images folder to "images.old" and copies over Joomla 1.5 "images" folder.
Success: moving onto the next step
Fixing at this stage: ensure folder write permissions, valid "target directory"

 

[10] [extensions]

Activity: jUpgrade looks for any third-party extensions that it supports and migrates the data for each one
Success: the message ";|;10;|;extensions;|;11" appears, followed by a list of extensions whose data has been migrated
Fixing at this stage: ensure database write permissions, valid "table" and "prefix for new database" Parameter settings, remove duplicate tables from previous (failed) migration and try again

 

[12] [ready]

Activity: jUpgrade migration complete
Success: the section for this step is displayed
Fixing at this stage: nothing to fix, migration was completed successfully.

 

 

Manually removing a failed migration

The latest version of jUpgrade (2.5.1) has a feature called "Delete previous migration" which runs a clean-up script before every migration that will remove any database tables, files or folders which were created, inserted or left over from a previous migration or failed attempt.

If for any reason this script fails while running the clean-up, you can "wipe the slate clean" and start fresh by following these instructions:

1. remove ROOT/tmp/joomla25.zip and ROOT/tmp/size.tmp
2. remove ROOT/jupgrade directory
3. delete all j17_ tables (except j16_jupgrade_categories and j16_jupgrade_menus)
4. REMOVE OLD jUpgrade installation and install the version 2.5
5. Set "Skip download" to 'No'
6. F5 to reload the browser
7. Run upgrade

 

 

Tackling specific issues

All steps appear at once and "Start jUpgrade" button does nothing when clicked

jUpgrade makes extensive use of javascript, in particular MooTools, in order to begin and proceed through the migration process. This includes the functions that operate the "Start jUpgrade" button as well as hiding the step panels and revealing them at the appropriate stage.

If the necessary javascript library is not available or has not been loaded, the button will appear with all the steps listed in a column before the migration starts.

To fix this error, make sure the MooTools 1.2 Upgrade plugin has been installed and enabled in the Plugin Manager.

 

 

"Mootools 1.2 not loaded. Please enable "System - Mootools Upgrade" plugin."

jUpgrade has been written for use with the MooTools 1.2 javascript library, and this message appears when jUpgrade detects that the MooTools 1.2 plugin that it requires to function has not been installed or is not yet enabled.

To fix this error, follow the link generated for the message to get redirected to the Plugin Manager (or access that section directly), locate the "System - Mootools Upgrade" plugin and make sure it is enabled.

To help avoid running into any MooTools javascript-related errors during the migration, also make sure that the "MooTools Upgrade" plugin is first in the order of System plugins loaded (a simple way to do this would be to assign the plugin an order number of zero "0" and saving the order list). This will ensure that this plugin runs before any other javascript plugins that might interfere and reserves the necessary variables in memory for jUpgrade's use.

The "MooTools 1.2 Upgrade" plugin comes loaded with all standard Joomla! installations since v1.5.19, so Joomla! sites of a previous version will have to be updated (the latest version of Joomla! at the time of writing is 1.5.25).

Alternatively, you can download and install the "MooTools 1.2 Upgrade" plugin separately on Joomla! installs with versions previous to 1.5.19, as that will fulfill the MooTools requirement for jUpgrade. It is highly recommended, however, to run jUpgrade after updating Joomla! to the latest version, as it has the most recent fixes and adjustments made by the Joomla! team and will maximize migration success.

 

 

"401: jupgrade_categories table not exist"

"402: jupgrade_menus table not exist"

"403: jupgrade_modules table not exist"

"404: jupgrade_steps table not exist"

When jUpgrade gets installed, one of the things it does is CREATE TABLE IF NOT EXISTS IF NOT EXISTS IF NOT EXISTSs in the Joomla! 1.5 database that help move the migration through each step. This includes tables for:

• converting sections into categories for Joomla! 2.5's category-only structure
• converting menu and menu item references to accommodate 2.5's new menu ID organization
• converting module and parameter references to accommodate 2.5's new module ID organization
• checking that a step in the migration process has been completed before moving on to the next one

If these tables have not been created, jUpgrade cannot proceed with the migration. To fix this, simply uninstall and reinstall jUpgrade, and the script that makes the tables should run and resolve the issue. (Obviously to create these tables the administrator must have the relevant permissions, but if the site is on a shared host then the server host administrator should be contacted for further assistance.)

 

 

"405: jupgrade_steps is not valid"

One of the tables crucial to jUpgrade's migration process, labelled "jupgrade_steps", stores the values for each step of the process and whether they have been completed before moving on to the next one. There are ten records stored within this database: nine of them define the sections that are migrated during the "Upgrading progress..." step, and the last concerns the migration of third party extensions.

This error message appears when the "jupgrade_steps" table has been corrupted or does not have the exact ten records which jUpgrade needs present. To fix this, simply uninstall and reinstall jUpgrade, and the script that adds the required records to the "jupgrade_steps" table should run and resolve the issue.

 

 

 

"406: cURL not loaded"

jUpgrade uses the cURL PHP library in order to handle the download and decompression of the new Joomla! 2.5 zip file, so having this library installed and enabled in the PHP configuration is required for jUpgrade to proceed with migration.

To fix this error, the line "extension=php_curl.dll" must be present in the php.ini file configured for the site's hosting server. Access to this file will depend on whether the site is being hosted locally and the administrator has full access, or whether the site is being hosted on a remote server, possibly shared, and the client will require the administrator's assistance to make the modification.

(Please note: in Linux environments, the line would read "extension=php_curl.so" .)

If you are running a localhost using XAMPP, 1) Open the php.ini file inside the "xampp\php" folder 2) Locate the line ;extension=php_curl.dll and remove the semi-colon 3) If the line does not exist, add it to the bottom of the php.ini file 4) Save the file and restart XAMPP (or stop and start both the Apache and MySQL services)

If your site is hosted on a remote server and you don't have access to the php.ini file, you will have to ask the server administrator to make this adjustment for you and restart the server.

You can check if cURL is installed and present by clicking on "Help >> System Info" in the main Joomla! navigation bar, then clicking on the "PHP Information" tab and scrolling down until the "cURL" section appears and displays the "cURL support" status.

There is also a manual method of testing for the php_curl module using the following instructions:

1) Create a new .php file (for e.g.: info.php) and add the following code into a text editor as the contents of the file:

<?php
// Show all information, defaults to INFO_ALL
phpinfo();
// Show just the module information.
// phpinfo(8) yields identical results.
phpinfo(INFO_MODULES);
?>

2) Upload this .php file to the root of your site (using FTP for example)
3) Now access this file using a browser (e.g.: www.yoursite.com/info.php) The page that displays will reveal whether your host supports and has enabled the cURL library.

Here are some more resources to learn about cURL and how to set it up:
http://curl.haxx.se/libcurl/php/
http://php.net/manual/en/book.curl.php
http://stackoverflow.com/questions/1347146/how-to-enable-curl-in-php

(// "CURLOPT_FOLLOWLOCATION" doesn't work with safe_mode or open_basedir)

 

 

 

"407: ".JPATH_ROOT." is unwritable"

"408: {$tmp} is unwritable"

Part of the migration process involves downloading the Joomla! distro selected in the Parameters screen, storing it in the /tmp folder of the Joomla! 1.5 site, extracting the contents of the distro package into a folder on the root, modifying the "configuration.php" file and copying several files and folders.

For all this to happen, the administrator requires the relevant permissions to modify the contents of their Joomla! 1.5 site folder. Otherwise jUpgrade will not have a place to store the files it needs to work with and the migration process halts.

You can check which folders are writable by clicking on "Help >> System Info" in the main Joomla! navigation bar, then clicking on the "Directory Permissions" tab to visually inspect which folders are "Writable".

To resolve this, the administrator needs to modify the permissions of the "root" and /tmp folders to allow making edits. You can use an extension such as eXtplorer to assist with this, alternatively you can set these permission using an FTP program such as FileZilla, or if on a shared host ask the server admin to assist with this. The permission level should be set to CHMOD 750 or 777.

If security is a concern on a shared hosting environment, the server admin can pre-create the jupgrade folder (or whatever label the "target directory" will have) and allow permissions to that folder alone for the purposes of the migration. In such a case, make sure "Skip Download" and "Skip Decompress" are selected and the "target directory" defined in the Parameters screen.

 

 

"409: PHP 5.2+ or greater is required"

Like all Joomla! components, jUpgrade has been written using the PHP programming language, and as such requires that PHP libraries be present to work. As time moves on and the PHP language develops, new versions are released with new functions and ways of writing code that make previous methods obsolete and eventually unusable.

Just as Joomla! 2.5 requires PHP v5.2 or greater, so to does jUpgrade. This message will appear when your version of PHP is below v5.2, and the migration will not be able to proceed because jUpgrade requires methods and functions that are not available in previous versions.

To resolve this issue, update the PHP installation on the server with the latest 5.2.x or 5.3.x release and restart the server, or if on a shared host ask the host provider for assistance. You can check the version installed by clicking on "Help >> System Info" in the main Joomla! navigation bar, then clicking on the "PHP Information" tab. The version number will be clearly displayed.

 

 

 

"410: MySQL 5.0+ or greater is required"

Joomla! installations work with databases to store the site information and settings, the most popular database type being MySQL. Much of the migration process in jUpgrade is handled through database queries, and these queries have been written to work with MySQL v5.0 or above.

Just as Joomla! 2.5 requires MySQL v5.0 or greater, so to does jUpgrade. This message will appear when your version of MySQL is below 5.0, and the migration will not be able to proceed because the minimum requirement has not been met.

To resolve this issue, update the MySQL installation on the server with the latest 5.x release and restart the server, or if on a shared host ask the host provider for assistance. You can check the version installed by clicking on "Help >> System Info" in the main Joomla! navigation bar, then clicking on the "PHP Information" tab. The "MySQL version" will be among the other details displayed.

 

 

 

"411: You must to disable 'safe_mode_gid' on your php configuration"

 

 

 

 

"412: Your destination prefix is the same of the original site"

As jUpgrade installs in the Joomla! 1.5 site , the tables it makes go into the site's database. The default prefix for 1.5 databases is "jos_", while the default prefix for 2.5 databases is "j17_" (from previous version, will be updated soon).

When jUpgrade migrates the site, the tables for both the 1.5 and 2.5 sites will be stored within the same database. jUpgrade does not allow the migration to proceed if it detects the prefix of the old database (from where it is pulling data) is the same as the prefix of the new database (where data is being transferred). If it did, you would risk breaking the migration and, more importantly, breaking the original 1.5 site database.

To resolve this issue, simply open the Parameters screen and ensure that the old and new table prefixes are different.

 

 

 

 

"Warning: set_time_limit( ) has been disabled for security reasons in..."

"Warning: set_time_limit(): Cannot set time limit due to system policy in..."

"Notice: Undefined property: stdClass::$timelimit in..."

While it can function without it, jUpgrade first opts to check for and use the value set in the server's PHP configuration for "set_time_limit". The "set_time_limit" function:

"Sets the number of seconds a script is allowed to run. If this is reached, the script returns a fatal error. The default limit is 30 seconds or, if it exists, the max_execution_time value defined in the php.ini.

When called, set_time_limit() restarts the timeout counter from zero. In other words, if the timeout is the default 30 seconds, and 25 seconds into script execution a call such as set_time_limit(20) is made, the script will run for a total of 45 seconds before timing out."
(http://php.net/manual/en/function.set-time-limit.php)

This function has legitimate purposes, however it can also potentially leave open a security hole. For this reason, most shared hosting services do not enable this function.

If any of the above messages are displayed, it is because jUpgrade is looking for the "set_time_limit" value, expecting it in order to proceed, but it is not available on the server. To resolve this, set the "Disable set_time_limit" to "Yes" in the Parameters screen so jUpgrade will ignore it as part of the initial checks.

In a desperate situation, you can remove or comment out line 43 of the "jupgrade.class.php" file in the "{root}/administrator/components/com_jupgrade/includes/" folder, which looks for the value of the server's "set_time_limit" to proceed.

 

 

 

"Fatal error: Uncaught exception 'JDatabaseException' with message 'Table 'j17_banners' already exists"

As part of the "Installing Joomla 2.5" step, the necessary tables are created in the the database. On a failed migration attempt, these tables need to be removed (or dropped) from the database to clear the path for a fresh install.

If you get this message, it means these tables have not been removed before jUpgrade was run. To fix this, set "Clean-up" to "Yes" in the Parameters screen and run jUpgrade. This feature should automate the clean-up and resolve the issue.

Alternatively, if that does not help, access your 1.5 site's database (such as through "phpmyadmin"), and locate and manually remove all tables that begin with the prefix that has been set as the "Prefix for new database" in the Parameters screen.

 

 

 

 

"Migrating undefined" or "[undefined][undefined]"

There may come an instance where the process will get stuck while migrating data for a specific component and (with "Debug mode" enabled) an error similar to "Migrating undefined" or "[undefined][undefined]" will be displayed.

Some causes and remedies include:

• a migrate_xxx.php file that is being requested for by jUpgrade is not available or accessible
  (these files are stored in the {root}/administrator/components/com_jupgrade/includes/ folder, labelled "migrate_xxx.php" where "xxx" is the section of content being transferred at the time.)
  To fix: uninstall and reinstall jUpgrade (to restore all required files) and try again.

• the database table from which content is being transferred is corrupt or has been modified
  (jUpgrade requires that no modifications have been made to any of the core tables themselves, otherwise the migration can run into problems when dealing with custom fields)
  To fix:download and install a maintenance component such as "Admin Tools!" and run a database integrity check and repair. Alternatively the database may have to be repaired manually using "phpmyadmin" or a similar interface. A solution for databases with custom fields is being looked into, but for the moment those must be migrated manually, or if they interfere with the migration, removed. (Of course a backup should be run before any such operation.)

• the migration runs into an issue attempting to copy content over to a database which already has content (from a previous migration, failed or not).
  To fix: remove all the tables created for the new Joomla! install during the migration and run jUpgrade again.

• the Javascript which handles the migration process has run into a problem
  To fix:check in the Plugin Manager to ensure that any system plugins related to javascript libraries, apart from the "MooTools Upgrade" plugin (which is required) has been disabled and try running jUpgrade again.

 

 

"Collation error"

All tables must have the collation of utf8_general_ci , and all applicable columns within those tables must have that collation as well.