This project seems to be missing a LICENSE document.

Under what license is the code in this repository?

I have what looks like a bug with this tool.
I've successfully installed the migration tool on both legacy version and the most up-to-date version of concrete (8.3.2). I created a batch and exported xml content successfully from the legacy site and created a new empty batch in the new site. But when clicking on the 'Add Content to Batch' button, it does nothing. It does not show the pop up dialogue box to upload the xml file.
Can anyone confirm this is a bug? I am testing this on a sub-folder - would this make a difference?

I'm shifting a 5.6.3.4 site to 8.1.0
Was surprised when attempting install of addon_migration_tool_legacy to see that it required version 5.6.3.5b but went ahead and updated to that. Seemed to successfully produce a batch.
But now in my new 8.1.0 install I'm getting alert 'This package requires concrete5 version 8.2.0a1 or greater' when installing addon_migration_tool
I don't want to use v8.2.0a1. Does this tool really require this software version, or am I missing something?

Any interest in converting this add-on into a Composer Package?

I could send a pull request moving the files around and adding the composer.json, if that's desired?

There are situations where one would like to migrate a 5.7 site to 5.8 without performing an in-place upgrade for example when moving a site between different hosts.

It will be very convenient to have the latest branch that supported 5.7.x available under Releases

MariaDB doesn't seem to support certain format.

Under certain circumstances, you need to convert XML.

For instances, I got the following error when I tried to use Majorca theme

An exception occurred while executing 'INSERT INTO btCoreConversation (bID, cnvID, enablePosting, paginate, itemsPerPage, displayMode, orderBy, enableOrdering, enableCommentRating, enableTopCommentReviews, displaySocialLinks, reviewAggregateAttributeKey, displayPostingForm, addMessageLabel, dateFormat, customDateFormat) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params ["251", "6", "1", "1", "50", "threaded", "date_asc", 0, "1", 0, 0, "", "top", "Add Message", "default", ""]: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: '' for column 'reviewAggregateAttributeKey' at row 1

In content.xml, you must change

<reviewAggregateAttributeKey><![CDATA[]]></reviewAggregateAttributeKey>

to

<reviewAggregateAttributeKey><![CDATA[0]]></reviewAggregateAttributeKey>

And you cannot seem to use self-closing tags such as <uID />. You need to change it to <uID><![CDATA[0]]></uID>.

@nipper-onside (nipper15 on concrete5.org) has the example of fix to MariaDB here.
https://www.concrete5.org/marketplace/themes/palette/support/error-on-install/

PortlandLabs\Concrete5\MigrationTool\Entity\Publisher\Log\Object\LoggableObject and PortlandLabs\Concrete5\MigrationTool\Entity\Publisher\Log\Object\Traits\StackTrait define the same property ($id) in the composition of PortlandLabs\Concrete5\MigrationTool\Entity\Publisher\Log\Object\GlobalArea. This might be incompatible, to improve maintainability consider using accessor methods in traits instead. Class was composed

Started with 8.1 install and pulled down 8.2.0a2 to be able to use the current version of the migration tool, and ended up with this error on all pages.

Installing the package on a clean 5.7.5.3 gives the following error:

An unexpected error occurred.
Class 'Concrete\Core\Backup\ContentImporter\ValueInspector\InspectionRoutine\PageRoutine' not found

The package then appears partially installed but there is no interface.

Is there any good way to export or import scrapbook proxy block instances?

Also tried v8.4.4 > v8.4.4 and this also imports with no error but the stack is not editable and when dragging an imported stack on to the page there is nothing in the stack. The XML files shows the exact same import data for the same stack from either v8.1.0 or v8.4.4. I would expect the XML data is good since the export was done from v8.4.4 and the import was done from v8.4.4.

I tried it with a single very simple Stack. Same results. Here is the XML:

<?xml version="1.0" encoding="UTF-8"?> <concrete5-cif version="1.0"> <stacks> <stack name="Vertical 50 Spacer" path="/vertical-50-spacer"> <area name="Main"> <blocks> <block type="html" name=""> <data table="btContentLocal"> <record> <content><![CDATA[<div style="margin-top:50px"></div>]]></content> </record> </data> </block> </blocks> </area> </stack> </stacks> </concrete5-cif>

Great tool BTW but C5.8 won't import from a c5.6.3.5b1 export - get error 'This does not appear to be a valid concrete5 mapping file'

The start of the 5.6 export.xml file looks correct but I'm not 100% sure...

<?xml version="1.0" encoding="UTF-8"?>
<concrete5-cif version="1.0"><pages><page name="Sheets" path="/shop/sheets" filename="" public-date="2014-04-18 13:20:00"

Has anyone else seen this?

Cheers

This happens when I am adding batch to site. There are some video files not uploaded as I am going to change format to mp4. Do you need the XML file to? Hope this helps you Andrew.
Alan

Website System Environment Information
concrete5 migration issue2.txt

In debug mode:

concrete5 has encountered an issue2.zip

Just migrated over 700 pages site from 5.6 to 8.

I've realized that Migration Tools doesn't really preserve sitemap order.
I manually scan old and new site back to order.

I know that it would require a bit of restructure the code.

But it would be nice to preserve the site map order.

There is a bug in src/PortlandLabs/Concrete5/MigrationTool/Publisher/Routine/AbstractPageAction.php line 69

$data['handle'] = $path;

should be

$data['cHandle'] = $path;

This section of code creates placeholder parent pages if they don't exist as part of the import. Most of the time it works fine because it auto-creates a slug/handle based on the page name. However, my use case is importing from WP. Slight variations in how WP and C5 generate slugs means that on occasion this generates a page that doesn't match the actual parent path of the page being imported. Other code tries to lookup the created parent based on the path but returns null because the paths don't match.

I spent 8 hours of my life tracking down this stupid bug yesterday :(

Hi There,

I am trying to migrate between to servers, both having concrete version 8.2.1. I added my content to the export batch. That worked so far, besides for Page Types.

Reproduce:

1. Click on Add Content to Batch
2. Choose "Page Types" in Dropdown and click "go"
3. I get the Exception

Call to a member function isDefault() on null within the method

public function getResultColumns(ExportItem $exportItem)
    {
        $t = \Concrete\Core\Page\Type\Type::getByID($exportItem->getItemIdentifier());
        if (is_object($t)) {
            if (method_exists($t, 'getSiteTypeObject')) {
                $siteType = $t->getSiteTypeObject();
                if (!$siteType->isDefault()) {
                    return array($siteType->getSiteTypeName() . ': ' . $t->getPageTypeDisplayName());
                }
            }
 
            return array($t->getPageTypeDisplayName());
        }
 
        return array();
    }

When I leave Page Types away and just try to export the Rest of the Content, I get the following error after hitting "Export Batch

Call to a member function loadController() on null within the method

public static function getByID($btID)
    {
        $em = \ORM::entityManager();
        $bt = $em->getRepository('\Concrete\Core\Entity\Block\BlockType\BlockType')->find($btID);
        $bt->loadController();
 
        return $bt;
    }

Any idea? Is migration FROM 8.2.1 not supported?

Trying to export a multilingual site c5 8.3.2, when creating the batch going into add pages it is only showing the top locale.
If I select the top level of the next language it finds no pages.

Any buddy help me i tried multiple time but migration not succesfully. i want concrete5.6.3.4 ti latest version update can we provide steps for updation asap.

Class 'Concrete\Package\MigrationTool\Page\Controller\DashboardPageController' not found
i update concrete5.6.3.4 to concrete5.7.3 but this error occure

Errors when try to rescan batch and publish batch.

Error said :
PHP Fatal error: Call to undefined method PortlandLabs\\Concrete5\\MigrationTool\\Publisher\\Routine\\PublishPageContentRoutine::getTargetItem() in /var/www/html/tmp/packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Publisher/Block/AreaLayoutPublisher.php on line 41, referer: http://url.com/index.php/dashboard/system/migration/import/view_batch/a7f8ddb9-cc97-11e6-bdc0-000d3ab3cf4c

I'm attempting an installation of addon_migration_tool-master from here, following addon manual installation instructions from concrete5.org. As per, I have unzipped, moved /packages/migration_tool to site's /packages directory and upon reloading the site's /index.php/dashboard/extend/install page, I am not seeing the package as awaiting installation. I have been successful using this method on this site (a new site containing sample content) to install Cloneamental and Community Store addons.
environmental information is as below:

Can you please tell me what I am missing in order to use this tool? or can you please post a link to documentation for concrete5 cif so that i may hand-make content.xml files for my new sites without this tool.

concrete5 Packages

Cloneamental (0.9.3), Community Store (1.1.4)

concrete5 Overrides

languages/cs_CZ/LC_MESSAGES/messages.mo, languages/cs_CZ/LC_MESSAGES, languages/cs_CZ, languages/da_DK/LC_MESSAGES/messages.mo, languages/da_DK/LC_MESSAGES, languages/da_DK, languages/de_DE/LC_MESSAGES/messages.mo, languages/de_DE/LC_MESSAGES, languages/de_DE, languages/el_GR/LC_MESSAGES/messages.mo, languages/el_GR/LC_MESSAGES, languages/el_GR, languages/en_GB/LC_MESSAGES/messages.mo, languages/en_GB/LC_MESSAGES, languages/en_GB, languages/es_ES/LC_MESSAGES/messages.mo, languages/es_ES/LC_MESSAGES, languages/es_ES, languages/es_PE/LC_MESSAGES/messages.mo, languages/es_PE/LC_MESSAGES, languages/es_PE, languages/es_PY/LC_MESSAGES/messages.mo, languages/es_PY/LC_MESSAGES, languages/es_PY, languages/fi_FI/LC_MESSAGES/messages.mo, languages/fi_FI/LC_MESSAGES, languages/fi_FI, languages/fr_FR/LC_MESSAGES/messages.mo, languages/fr_FR/LC_MESSAGES, languages/fr_FR, languages/it_IT/LC_MESSAGES/messages.mo, languages/it_IT/LC_MESSAGES, languages/it_IT, languages/ja_JP/LC_MESSAGES/messages.mo, languages/ja_JP/LC_MESSAGES, languages/ja_JP, languages/nb_NO/LC_MESSAGES/messages.mo, languages/nb_NO/LC_MESSAGES, languages/nb_NO, languages/nl_NL/LC_MESSAGES/messages.mo, languages/nl_NL/LC_MESSAGES, languages/nl_NL, languages/pl_PL/LC_MESSAGES/messages.mo, languages/pl_PL/LC_MESSAGES, languages/pl_PL, languages/pt_BR/LC_MESSAGES/messages.mo, languages/pt_BR/LC_MESSAGES, languages/pt_BR, languages/ru_RU/LC_MESSAGES/messages.mo, languages/ru_RU/LC_MESSAGES, languages/ru_RU, languages/sv_SE/LC_MESSAGES/messages.mo, languages/sv_SE/LC_MESSAGES, languages/sv_SE, languages/tr_TR/LC_MESSAGES/messages.mo, languages/tr_TR/LC_MESSAGES, languages/tr_TR, languages/cs_CZ/LC_MESSAGES/messages.mo, languages/cs_CZ/LC_MESSAGES, languages/cs_CZ, languages/da_DK/LC_MESSAGES/messages.mo, languages/da_DK/LC_MESSAGES, languages/da_DK, languages/de_DE/LC_MESSAGES/messages.mo, languages/de_DE/LC_MESSAGES, languages/de_DE, languages/el_GR/LC_MESSAGES/messages.mo, languages/el_GR/LC_MESSAGES, languages/el_GR, languages/en_GB/LC_MESSAGES/messages.mo, languages/en_GB/LC_MESSAGES, languages/en_GB, languages/es_ES/LC_MESSAGES/messages.mo, languages/es_ES/LC_MESSAGES, languages/es_ES, languages/es_PE/LC_MESSAGES/messages.mo, languages/es_PE/LC_MESSAGES, languages/es_PE, languages/es_PY/LC_MESSAGES/messages.mo, languages/es_PY/LC_MESSAGES, languages/es_PY, languages/fi_FI/LC_MESSAGES/messages.mo, languages/fi_FI/LC_MESSAGES, languages/fi_FI, languages/fr_FR/LC_MESSAGES/messages.mo, languages/fr_FR/LC_MESSAGES, languages/fr_FR, languages/it_IT/LC_MESSAGES/messages.mo, languages/it_IT/LC_MESSAGES, languages/it_IT, languages/ja_JP/LC_MESSAGES/messages.mo, languages/ja_JP/LC_MESSAGES, languages/ja_JP, languages/nb_NO/LC_MESSAGES/messages.mo, languages/nb_NO/LC_MESSAGES, languages/nb_NO, languages/nl_NL/LC_MESSAGES/messages.mo, languages/nl_NL/LC_MESSAGES, languages/nl_NL, languages/pl_PL/LC_MESSAGES/messages.mo, languages/pl_PL/LC_MESSAGES, languages/pl_PL, languages/pt_BR/LC_MESSAGES/messages.mo, languages/pt_BR/LC_MESSAGES, languages/pt_BR, languages/ru_RU/LC_MESSAGES/messages.mo, languages/ru_RU/LC_MESSAGES, languages/ru_RU, languages/sv_SE/LC_MESSAGES/messages.mo, languages/sv_SE/LC_MESSAGES, languages/sv_SE, languages/tr_TR/LC_MESSAGES/messages.mo, languages/tr_TR/LC_MESSAGES, languages/tr_TR

concrete5 Cache Settings

Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 1 minutes.

Server Software

Apache/2.4.18 (Ubuntu)

Server API

apache2handler

PHP Version

7.0.8-3ubuntu3

PHP Extensions

apache2handler, bz2, calendar, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, Phar, posix, readline, Reflection, session, shmop, SimpleXML, sockets, SPL, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, Zend OPcache, zip, zlib

PHP Settings

max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
sql.safe_mode - Off
upload_max_filesize - 2M
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - no value
session.gc_maxlifetime - 1440
opcache.max_accelerated_files - 2000
opcache.max_file_size - 0
opcache.max_wasted_percentage - 5

When trying to migrate the content of 5.6 to v8.4, internal links in the content blocks stay empty. The internal linked files are correctly linked.

XML File:
<a href="{ccm:export:page:/faq/categorie/questionanswer}" title="Link title">Link</a>

After import:
<a title="Link title" href="">Link</a>

Is there anyway to save the paths? Guess the pages are not linked because they don't exist yet.

Hi,
Block Container Class (Disable Grid Container/ Enable Grid Container) does not export to xml.

Scenario:

1. Created a new batch in 5.6 (5.6.3.3) named "Company". Includes all subpages under the Company page.
2. Imported this batch into 5.7 (5.7.5.6) under a new "Company" batch.
3. There's many links on these pages that reference other pages in this Company section (other subpages).
4. I'm getting warning errors for all these links, similar to: Referenced page at path /company/about-us cannot be found in the site or in the current content batch.

This page does in fact exist in the current batch. Thoughts on why this is happening?

Thanks for the great tool, it should save me hours of time!

FYI, the 5.6 site is on a production server and the 5.7 site is on my local machine (using MAMP). Not sure if that matters or not.

When trying to export stacks, '$stacks = $list->getResults();' fails and it errors out on packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Exporter/Item/Type/Stack.php line 97 ( Invalid argument supplied for foreach() ) even though site has about 40 stacks.

I have a CIF file that I want to import. When I go to System & Settings -> Migration Tool -> Import Content, click on Add Batch, and try to add a CIF XML file (in the Provide Mapping Presets field), I get this error:

This does not appear to be a valid concrete5 mapping file.

How do I specify that I want to import a CIF file, not a mapping file?

I should mention, I'm using the master branch, and the 59935b5 commit.

I have run into an issue with exporting files, where the file ID basically overrides other pre-existing files on the instance where files are being imported.

So, I basically just need to know what files to edit to make it so only the Filename is exported / imported, and NOT the FileID.

You can now choose from a specified format when providing a file to the content importer:

The concrete5 import format is unchanged, but there is a new Wordpress option. This option currently doesn't do anything – we need to implement it. To implement it we'll need to do the following:

1. Open the file packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Importer/Wordpress/WordpressParser.php.
2. Add any validation code that w can to the validateUploadedFile method. This should check the uploaded file for mime type, well-formedness, expected format, whatever – and if it doesn't match add an error into the passed error object.
3. Implement getContentObjectCollections($file). This method is responsible for parsing the passed $file (which is just a link to a file on the server, typically which has been uploaded via the dialog form in the page), parsing the file, and populating concrete5 migration entity objects and object collections. The returned array is an array of \PortlandLabs\MigrationTool\Entity\Import\ObjectCollection objects.

Number 3 won't really make much sense without viewing how the concrete5 importer works. Open up packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Importer/CIF/CIFParser for an example of how we're parsing the concrete5 XML files for content.

First we make the CIF manager class:

    $manager = \Core::make('migration/manager/importer/cif');

This is just an instance of this class: \PortlandLabs\Concrete5\MigrationTool\Importer\CIF\Manager.php.

Then we parse our passed file using simplexml:

    $simplexml = simplexml_load_file($file);

Then we loop through all the registered CIF importer drivers (registered in the manage class) and call the parse method on the full XML for each driver. The driver is responsible for parsing the XML into the entity objects, which get added to the object collection. Once the object collections are full of all the entities found in the content, they get passed back and you're done!

The wordpress import will be DRAMATICALLY simpler than the concrete5 one. For one, the concrete5 import format can describe everything concrete5 can do. I imagine the wordpress import will really just stick to importing some pages, maybe some main content blocks in the main area on those pages. You'll be adding a Manager class to the \PortlandLabs\Concrete5\MigrationTool\Importer\Wordpress namespace, and all the different methods that go with each of those instances, like an interface for parsing whatever content file wordpress has.

Blocks that were copied but never modified seem to be omitted.

When adding content to an import batch the following exception is raised

Call to undefined method PortlandLabs\Concrete5\MigrationTool\Entity\Import\BlockValue\ImportedBlockValue::getAreaLayout() in file \packages\migration_tool\src\PortlandLabs\Concrete5\MigrationTool\Batch\ContentMapper\Type\BlockType.php","line":44

$columns = $block->getBlockValue()->getAreaLayout()->getColumns();

Using concrete5 ver 8.2.1 and migration_tool ver 0.8.0

I have been using the migration tool from a 5.6.3.4 site to a clean 5.7.5.6 instal (on wampserver) and I keep getting on import
"An exception occurred while executing 'insert into Pages (cID, ptID, cParentID, uID, cInheritPermissionsFrom, cOverrideTemplatePermissions, cInheritPermissionsFromCID, cDisplayOrder, pkgID) values (?, ?, ?, ?, ?, ?, ?, ?, ?)' with params ["209", "6", null, 1, "TEMPLATE", null, "153", 0, 0]: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'cParentID' cannot be null"
Any quick thoughts on the cause of this error?

Okay, I see there is an issue in the instal the db tables are damaged.

Okay odd, I just did another clean instal and after installing the migration tool it seems to delete all the tables after those beginning with M apart from a handful...

We are having an issue during the import process. The following is the error in the concrete5 logs.

Exception Occurred: /home/phoenix/public_html/c58/packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Batch/Validator/Page/Content/FileItemValidator.php:31 Call to undefined method Concrete\Core\Backup\ContentImporter\ValueInspector\Item\FileItem::getPrefix() (1)

After uploading the xml file, it says under pages: Load error! (Internal Server Error)
For Status it just thinks and says: Computing Batch Status

We have used the same add-on on another site and it works fine, the C58 Version is 8.3.2. The version of the problem site is 8.2.1, but this Migration Tool says that version is included.

We checked the file size, and that's not it, as we are just doing a few test pages. We tried to clear the cache as well, and no change.

Migration Tool v.0.5.4 for C5.7+

I am unable to import an XML file which was created by the legacy export function. the legacy migration_tool worked just fine.
I have rebooted. I have tried different browsers. I have reinstalled the migration_tool. Nothing.
The "Browse..." button opens a dialog window (Windows 7) and I select the XML file and press "Open" but nothing happens. No error messages, nothing.
Would love to start migrating but with this issue I am stuck.
Please help.
-John

There is no option to add rss feeds to an export batch.

When importing site content that included an rss feed the following error is displayed

Referenced page feed blog cannot be found in the site or in the current content batch

using the migration tool to import attribute keys where they have category=“site” but getting error on import as "Driver [site] not supported" . This is transfer between 8.3.2 to 8.3.2 . I have attached the XML file.
export.txt

Error encountered while importing content from Concrete 5.7.5.13 to Concrete5 8.4.2

All errors in import batch fixed in Map Content

Migration tool 0.5.4 and 0.9.0 used for content migration.

Invalid argument supplied for foreach()

Details
/home/kenyavet/public_html/c5/concrete/blocks/share_this_page/controller.php(119): Whoops\Exception\ErrorException->null	
/home/kenyavet/public_html/c5/concrete/blocks/share_this_page/controller.php(119): Whoops\Run->handleError	
/home/kenyavet/public_html/c5/concrete/src/Entity/Block/BlockType/BlockType.php(665): Concrete\Block\ShareThisPage\Controller->save	
/home/kenyavet/public_html/c5/concrete/src/Page/Collection/Collection.php(964): Concrete\Core\Entity\Block\BlockType\BlockType->add	
/home/kenyavet/public_html/c5/concrete/src/Page/Page.php(2238): Concrete\Core\Page\Collection\Collection->addBlock	
/home/kenyavet/public_html/c5/packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Publisher/Block/StandardPublisher.php(51): Concrete\Core\Page\Page->addBlock	
/home/kenyavet/public_html/c5/packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Publisher/Routine/PublishPageContentRoutineAction.php(54): PortlandLabs\Concrete5\MigrationTool\Publisher\Block\StandardPublisher->publish	
/home/kenyavet/public_html/c5/packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Batch/Processor/Task/PublishContentTask.php(35): PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\PublishPageContentRoutineAction->execute	
/home/kenyavet/public_html/c5/concrete/src/Foundation/Processor/Action.php(74): PortlandLabs\Concrete5\MigrationTool\Batch\Processor\Task\PublishContentTask->execute	
/home/kenyavet/public_html/c5/concrete/src/Foundation/Processor/ProcessorQueue.php(66): Concrete\Core\Foundation\Processor\Action->execute	
/home/kenyavet/public_html/c5/packages/migration_tool/controllers/single_page/dashboard/system/migration/import.php(374): Concrete\Core\Foundation\Processor\ProcessorQueue->execute	
/home/kenyavet/public_html/c5/concrete/src/Controller/AbstractController.php(294): Concrete\Package\MigrationTool\Controller\SinglePage\Dashboard\System\Migration\Import->create_content_from_batch	
/home/kenyavet/public_html/c5/concrete/src/Controller/AbstractController.php(294): null->call_user_func_array	
/home/kenyavet/public_html/c5/concrete/src/Http/ResponseFactory.php(188): Concrete\Core\Controller\AbstractController->runAction	
/home/kenyavet/public_html/c5/concrete/src/Http/ResponseFactory.php(393): Concrete\Core\Http\ResponseFactory->controller	
/home/kenyavet/public_html/c5/concrete/src/Routing/DispatcherRouteCallback.php(34): Concrete\Core\Http\ResponseFactory->collection	
/home/kenyavet/public_html/c5/concrete/src/Http/DefaultDispatcher.php(130): Concrete\Core\Routing\DispatcherRouteCallback->execute	
/home/kenyavet/public_html/c5/concrete/src/Http/DefaultDispatcher.php(57): Concrete\Core\Http\DefaultDispatcher->handleDispatch	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/DispatcherDelegate.php(39): Concrete\Core\Http\DefaultDispatcher->dispatch	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/ThumbnailMiddleware.php(71): Concrete\Core\Http\Middleware\DispatcherDelegate->next	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/MiddlewareDelegate.php(38): Concrete\Core\Http\Middleware\ThumbnailMiddleware->process	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/FrameOptionsMiddleware.php(39): Concrete\Core\Http\Middleware\MiddlewareDelegate->next	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/MiddlewareDelegate.php(38): Concrete\Core\Http\Middleware\FrameOptionsMiddleware->process	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/CookieMiddleware.php(37): Concrete\Core\Http\Middleware\MiddlewareDelegate->next	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/MiddlewareDelegate.php(38): Concrete\Core\Http\Middleware\CookieMiddleware->process	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/ApplicationMiddleware.php(29): Concrete\Core\Http\Middleware\MiddlewareDelegate->next	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/MiddlewareDelegate.php(38): Concrete\Core\Http\Middleware\ApplicationMiddleware->process	
/home/kenyavet/public_html/c5/concrete/src/Http/Middleware/MiddlewareStack.php(86): Concrete\Core\Http\Middleware\MiddlewareDelegate->next	
/home/kenyavet/public_html/c5/concrete/src/Http/DefaultServer.php(85): Concrete\Core\Http\Middleware\MiddlewareStack->process	
/home/kenyavet/public_html/c5/concrete/src/Foundation/Runtime/Run/DefaultRunner.php(119): Concrete\Core\Http\DefaultServer->handleRequest	
/home/kenyavet/public_html/c5/concrete/src/Foundation/Runtime/DefaultRuntime.php(102): Concrete\Core\Foundation\Runtime\Run\DefaultRunner->run	
/home/kenyavet/public_html/c5/concrete/dispatcher.php(36): Concrete\Core\Foundation\Runtime\DefaultRuntime->run	
/home/kenyavet/public_html/c5/index.php(3): null->require	

We've found that during a batch status check that it will fail to find (many) files that have been imported because of spaces in their name.

For example, we'll see the message:

Note that there is a space between Booklet and 1
Here's the file in source website:

That same filename is what the file is exported as.

When it's imported into the batch, in the v8 file manager it looks like this:

It appears to have imported the title correctly, but the stored filename no longer has the space in it. In v8 I'm pretty sure the sanitize function used on filenames before importing the files is what is responsible for replacing the spaces with underscores.

So then when it comes to the batch matching, it seems to be trying to match up the files via their filename and not the title, and therefore doesn't find file due to the replaced spaces with underscores.

Our workaround in our last import was to go back to the original export.xml file and do some find and replaces in that for the files that we knew existed but weren't matching. Then we imported that and they were found fine.

I'd suggest the fix would be to apply the same sanitize function to the filename that is imported from the migration xml file. I did look for a fix myself but simply couldn't find where this is done.

We've migrated a site from 5.6.3.4 to 8.2.0a develop branch.

Then, we cannot delete the user.

@hissy said we need to uninstall migration tools to resolve this issue. But he also thinks migration tools cannot be uninstalled at the moment.

@biplobice, please pay attention to this issue.

I have followed the tutotial video on Andrew's website and got all to a stage to import and the Batch is showing no errors and I get this warning:

Declaration of PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\CreateStackStructureRoutine::getPageCollection(PortlandLabs\Concrete5\MigrationTool\Batch\BatchInterface $batch) should be compatible with PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\AbstractPageRoutine::getPageCollection(PortlandLabs\Concrete5\MigrationTool\Entity\Import\Batch $batch)

It means nothing to me. I followed the process as directed. The only issues may be the new 5.7 site is running on a localhost environment so possible has different PHP settings.

Also I had to edit the export.xml file as it had exported "<" and ">" as named HTML entities as oposed to symbols. But that seemed to work fine and made the file read properly. I have attached it in case.

export.xml.zip

Can you help clarify what might be going on?

Both Filter by Parent Page and Filter by Page Type don't provide a way of including the Home page when creating an Export batch.

• Filter by Parent Page doesn't include the page selected (parent) in the export
• Filter by Page Type doesn't have option for PageType None

This may also be related - Pages with PageType None cannot be exported. This can happen when a theme is uninstalled and some PageTypes removed which would cause Pages to have none for PageType.

During processing of an import batch the following exception is raised

An exception occurred while executing
'INSERT INTO btCoreConversation (bID, cnvID, enablePosting, paginate, itemsPerPage, displayMode, orderBy, enableOrdering, enableCommentRating, enableTopCommentReviews, reviewAggregateAttributeKey, displayPostingForm, addMessageLabel, dateFormat, customDateFormat) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params ["301", "3", "1", "1", "50", "threaded", "date_asc", 0, "1", 0, "", "top", "Add Message", "default", ""]: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'reviewAggregateAttributeKey' at row 1

Details

.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\AbstractMySQLDriver.php(115): Doctrine\DBAL\Exception\DriverException->null	
.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\DBALException.php(128): Doctrine\DBAL\Driver\AbstractMySQLDriver->convertException	
.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\Connection.php(1015): Doctrine\DBAL\DBALException->driverExceptionDuringQuery	
.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\PDOStatement.php(93): Doctrine\DBAL\Driver\PDOException->null	
.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\PDOStatement.php(91): PDOException->null	
.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\PDOStatement.php(91): PDOStatement->execute	
.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\Connection.php(1008): Doctrine\DBAL\Driver\PDOStatement->execute	
.\concrete\vendor\doctrine\dbal\lib\Doctrine\DBAL\Connection.php(715): Doctrine\DBAL\Connection->executeUpdate	
.\concrete\src\Database\Connection\Connection.php(205): Doctrine\DBAL\Connection->insert	
.\concrete\src\Legacy\Model.php(65): Concrete\Core\Database\Connection\Connection->Replace	
.\concrete\src\Block\BlockController.php(181): Concrete\Core\Legacy\Model->Replace	
.\concrete\src\Block\BlockController.php(197): Concrete\Core\Block\BlockController->performSave	
.\concrete\blocks\core_conversation\controller.php(288): Concrete\Core\Block\BlockController->save	
.\concrete\src\Entity\Block\BlockType\BlockType.php(655): Concrete\Block\CoreConversation\Controller->save	
.\concrete\src\Page\Collection\Collection.php(861): Concrete\Core\Entity\Block\BlockType\BlockType->add	
.\concrete\src\Page\Page.php(2224): Concrete\Core\Page\Collection\Collection->addBlock	
.\packages\migration_tool\src\PortlandLabs\Concrete5\MigrationTool\Publisher\Block\StandardPublisher.php(23): Concrete\Core\Page\Page->addBlock	
.\packages\migration_tool\src\PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\PublishPageContentRoutineAction.php(54): PortlandLabs\Concrete5\MigrationTool\Publisher\Block\StandardPublisher->publish	
.\packages\migration_tool\src\PortlandLabs\Concrete5\MigrationTool\Batch\Processor\Task\PublishContentTask.php(35): PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\PublishPageContentRoutineAction->execute	
.\concrete\src\Foundation\Processor\Action.php(74): PortlandLabs\Concrete5\MigrationTool\Batch\Processor\Task\PublishContentTask->execute	
.\concrete\src\Foundation\Processor\ProcessorQueue.php(66): Concrete\Core\Foundation\Processor\Action->execute	
.\packages\migration_tool\controllers\single_page\dashboard\system\migration\import.php(372): Concrete\Core\Foundation\Processor\ProcessorQueue->execute	

Using concrete5 ver 8.2.1 and migration_tool ver 0.8.0

hi
i've a 5.7.5.9 version installed and need to export and import on another 5.7.5.9, but the minimum version requred is 8.2.0a1.
how can i use this tool?
just change the in controller.php the version required or there are another pakage version?
thanks
bye

I am testing the migration tool with concrete 5.7.5.7 before starting migration of sites.
I got an error at the final stage of the import process despite having resolved all references and fixing all reported issues in the import batch

Steps to reproduce.
Installed concrete5 5.7.5.7 with sample content then installed the migration tool.
Exported the site by filtering by page (Home)
Installed a new site with empty content then installed a new theme and the migration tool.
Created a batch and added the previous site xml content
Resolved all issues identified in the batch
Clicked import batch to site which throws an error:-
Call to undefined method PortlandLabs\Concrete5\MigrationTool\Entity\Import\Area::getAreaHandle()
Site content is not imported.

Here is the same bug report which includes environment details

NormalizePagePathsTask#finish makes invalid page paths.

Example:

Original paths

• /2015/foo
• /2014/bar

Batch paths

• 15/foo
• 14/bar

Hello Concrete5,

I am trying out the migration tool from a legacy version to the newest version available.

Everything goes well with the tool but when i import the content to concrete5 v8 it seems to be working, but after importing every task i am redirected to the Batch overview page and nothing seems to be imported into concrete5.

There is no error message shown after the import tasks.

Here are some images:

Versions i have installed:

concrete5 Version Legacy

5.6.3

concrete5 Version

Core Version - 8.0.3
Version Installed - 8.0.3
Database Version - 20161216000000

Am i missing something?

Like to hear from you soon.

Kind regards,

Jeffrey Winston

When testing the Migration Tool import I have found the associations are not being imported. I exported all the current entries for a single entity and in the XML it has tags with a target and entry for example:

I don't see the associations imported alongside the Name and ID of the entry. It just ignores this attribute of the entry. Is there a reason for this? or a way to remedy this.

When adding content to an import batch an error dialog pops up before the process is completed.

Using concrete5 ver 8.2.1 and migration_tool ver 0.8.0

Error details
Error
$stack->setPosition($position); if ($node->area->blocks->block) { $blocks = $node->area->blocks->block; } elseif ($node->area->block) { // 5.6 $blocks = $node->area->block; } if (isset($blocks)) { $i = 0; foreach ($blocks as $blockNode) { if ($blockNode['type']) { $block = new StackBlock(); $block->setType((string) $blockNode['type']); $block->setName((string) $blockNode['name']); $bFilename = (string) $blockNode['custom-template']; if ($bFilename) { $block->setCustomTemplate($bFilename); } $value = $this->blockImporter->driver('unmapped')->parse($blockNode); if (isset($blockNode->style)) { $styleSet = $this->styleSetImporter->import($blockNode->style); $block->setStyleSet($styleSet); } $block->setBlockValue($value); $block->setPosition($i); $block->setStack($stack); $stack->getBlocks()->add($block); ++$i; } } } ++$position; $collection->getStacks()->add($stack); $stack->setCollection($collection); } } return $collection; }}

Possibly triggered in
.\packages\migration_tool\src\PortlandLabs\Concrete5\MigrationTool\Importer\CIF\Element\Stack.php

class Stack implements ElementParserInterface
{
    public function getObjectCollection(\SimpleXMLElement $element, Batch $batch)
    { // Bug likely triggered in this method   
        $this->simplexml = $element;
        $collection = new StackObjectCollection();
        if ($element->stacks) {
            $position = 0;
            foreach ($element->stacks->children() as $node) {
                $stack = $this->parseStack($node);
                $stack->setPosition($position); ```

Hi,

I wanted to try the add-on, but at install I get this error:

Declaration of PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\PublishSinglePageContentRoutine::getPageCollection(PortlandLabs\Concrete5\MigrationTool\Batch\BatchInterface $batch) should be compatible with PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\AbstractPageRoutine::getPageCollection(PortlandLabs\Concrete5\MigrationTool\Entity\Import\Batch $batch)

Surely it is because it is using PHP7, but how to fix?

I'm leaving this as a note.
When I have more time, I will investigate.

This is not really crucial, but on certain environment, it causes errors when importing.

Other environment such as MAMP works fine.

But when I was using Cloud9 which is running on AWS's Docker environment with ELB, I've got the following error.

Argument 1 passed to PortlandLabs\Concrete5\MigrationTool\Publisher\Routine\CreatePageStructureRoutineAction::execute() must implement interface PortlandLabs\Concrete5\MigrationTool\Batch\BatchInterface, null given, called in /home/ubuntu/workspace/packages/migration_tool/src/PortlandLabs/Concrete5/MigrationTool/Batch/Processor/Task/PublishContentTask.php on line 26 and defined

And when I check Google Chrome Dev Tools

I see that POST to /index.php/dashboard/system/migration/import/create_content_from_batch is returning 500 error.

I assume that load balancer may be causing this, and the presume solution is not to migration tools on complex server environment.

This could simply be a limitation, so I'm more so adding this for the benefit of others.

When you have a batch and you map the areas between the import and the new site, not all of the available areas appear in the drop down list.

Generally at this point we only have a home page in the site and no other pages. What we've found is that we need to go to the home page and change its page template (i.e. in the Design panel) to other templates. After changing the page template, the list of available areas for mapping changes to show the newly found areas.

It's then a case of changing through some of the different templates until all areas are mapped. It might be easiest to create a couple of new dummy pages, of the different templates.

I've got a feeling this isn't resolvable (without doing something like directly analysing the page template files themselves), so what I've described is basically a simple workaround.

Exported a section of my website from C5.6.3.5 using the migration tool. When I tried to import into c5.8.3.2 got the error - This does not appear to be a valid Concrete5 mapping file.

Here is the batch xml file: