I am migrating a website from Pimcore 3 to 4 (RC1) and I am struggling with the class mappings. Before this was done with a file website/var/config/classmap.xml in the new version there is a file in website/config/classmap.php (different directory and type). I followed the example, and cleared the cache several times (used to be required for Pimcore 3) but it has no effect, the class mappings are not applied. I cannot find any documentation on how to do it in Pimcore 4. The XML used to have a link to documentation in it, that is no longer the case.
This is my classmap.php:
return [
"Object\\Tag" => "Website\\Model\\Tag",
"Object\\Tag\\List" => "Website\\Model\\Tag\\Listing",
"Object\\News" => "Website\\Model\\News",
"Object\\News\\List" => "Website\\Model\\News\\Listing",
"Object\\Column" => "Website\\Model\\Column",
"Object\\Column\\List" => "Website\\Model\\Column\\Listing",
"Object\\Project" => "Website\\Model\\Project",
"Object\\Project\\List" => "Website\\Model\\Project\\Listing",
"Object\\Employee" => "Website\\Model\\Employee",
"Object\\Employee\\List" => "Website\\Model\\Employee\\Listing",
];
I tried digging around the code in pimcore/config/startup.php I found this:
// register class map loader => speed
$autoloaderClassMapFiles = array(
PIMCORE_CONFIGURATION_DIRECTORY . "/autoload-classmap.php",
PIMCORE_PATH . "/config/autoload-classmap.php"
);
I tried renaming the files to autoload-classmap.php but that did not work either.
How do I get this working?
Related
I need migrate 3400 rows from phpMyAdmin export to a custom content type over Drupal 8.
I tried to do with migration modules but, for example Migrate Plus and Migrate Tools are not compatible with my version of Drupal (8.1.1)
I wanted to import records using a PHP script.
I have tried many things but in many cases I said "undefined function" (by using, for example, entity_create) and more evidence I've done.
Example 1:
$new_page_values = array();
$new_page_values['type'] = 'my_content_type';
$new_page_values['title'] = "Titulo";
$new_page_values['path'] = "Path";
$new_page = entity_create('node', $new_page_values);
$new_page->save();
Example 2
$language = \Drupal::languageManager()->getCurrentLanguage()->getId();
$node = \Drupal\node\Entity\Node::create(array(
'type' => 'article',
'title' => 'The title',
'langcode' => $language,
'uid' => 1,
'status' => 1,
'body' => array('The body text'),
'field_date' => array("2000-01-30"),
//'field_fields' => array('Custom values'), // Add your custon field values like this
));
$node->save();
Example 3:
db_insert('example_entity')
->fields(array(
'type' => $entity->getEntityTypeId(),
'id' => $entity->id(),
'created' => REQUEST_TIME,
'updated' => REQUEST_TIME,
))
->execute();
I'm trying to run a .php file from the server console (php updateData.php)
Thanks and regards.
Javier, the migration in D8 is still a WIP.
My advise:
install the latest Drupal 8.1,
install the latest modules for migrate_tools, migrate_plus, migrate_source_csv and migrate_source_json. Preferably the latest beta-versions.
change your phpAdmin output to a csv-file.
Perhaps you need to create your custom entity. Migrate_tools has 2 examples for the migration. It also contains a csv example. The migration-process should seamlessly import your stuff.
Tips: YAML-files are extremely sensitive for grammatics such as spaces. And you shouldn't have to identify an external/migration database. But remember, what ever worked yesterday, today may be different. I am working on my migration for the last 6 months.
Migration process is a completely different story then the D7 one.
Edited: install Drush 8. Use Composer for the easy way. Drush is needed to run the migration script from commandline, manifest is obsolete.
Edited 2: IMO the best explanation for and why using the D8 migration.
Look at this site https://blog.liip.ch/archive/2016/05/04/using-the-new-drupal-8-migration-api-module.html. Your wish to use your own PHP seems mainly because you can't seem to use D8's migration?
We're using APCu as a data cache for PHP on a number of different installations - workstations, development and production servers. Unfortunately, the APCu API appears to be a moving target, and there is little to no official documentation (that I could find). At the moment, we're getting quite different return values for apcu_cache_info()...
With APCu 4.0.1, an entry looks like this:
[
'key' => 'the_entry_key',
'atime' => 1450646021,
'ctime' => 1450646021,
'mtime' => 1450650861,
'dtime' => 0,
// ...
]
With APCu 4.0.7, it looks like this:
[
'info' => 'the_entry_key',
'access_time' => 1450650861,
'creation_time' => 1450646021,
'modification_time' => 1450646021,
'deletion_time' => 0,
// ...
]
According to the source on GitHub, it now looks like this:
[
'info' => 'the_entry_key',
'access_time' => 1450650861,
'creation_time' => 1450646021,
'mtime' => 1450646021,
'deletion_time' => 0,
// ...
]
We've seen other sudden API changes in the past, like when apcu_sma_info() and apcu_cache_info() had to be called with the string "user" as the first parameter - until they didn't. I understand that these changes are related in some way with keeping or dropping compatibility with the old APC extension, but it's getting a little hard to guess how to interact with APCu.
Are these changes documented somewhere, with a version number we can check against? Are there going to be any more changes to this in the near future? How can I get notified about them, other than seeing my application break?
The documentation on php.net has nothing to say about this, and neither does the project's CHANGELOG file. The PHP change log doesn't mention this as a backwards incompatible change either (probably because APCu isn't bundled with PHP by default).
I've been using the filesystem adapter for cacheing data.
E.g..
$cache = StorageFactory::factory(array(
'adapter' => array(
'name' => 'filesystem'
'options' => array('ttl' => 1800, 'cache_dir' => './data/cache'),
),
));
But when using the getItem() function AFTER the TTL clocks over it returns false on success etc, which it should... However, I've noticed that the file remains on the system. Is there a way of forcing the use of the cached file?
Scenario being.. My cache is outdated, when it runs some expensive functions they return nothing or it times out.. So I'd like to use the cache instead!
Just wondering if thats possible?
Thanks!
Here is a useful link to the official ZF2 documentation for the specific StorageAdapter that you are using (filesystem).
I have zf2 DoctrineORMModule and DoctrienModule installed. I am trying to use the command tool to create mapping files and generate entities from these mapping files. (I know this isn't the preferred method, but this is how I'm going to do it. I have my reasons.)
I have a restful module configured and here is my Doctrine Configuration for this module.
// Doctrine config
'doctrine' => array(
'driver' => array(
'Restful_driver' => array(
'class' => 'Doctrine\ORM\Mapping\Driver\AnnotationDriver',
'cache' => 'array',
'paths' => array(__DIR__ . '/../src/Restful/Entities')
),
'orm_default' => array(
'drivers' => array(
'Restful\Entities' => 'Restful_driver'
)
)
)
)
I first run
doctrine orm:convert-mapping xml /to/my/dest/path --from-database --force
This will create my xml file with all the table info. This part works fine and I can view the xml that it created. Next I try to run
doctrine orm:generate-entities /to/my/dest/path --generate-annotations
--generate-methods
I don't get any errors but also I don't get any results either. The output from the previous command is.
No Metadata Classes to process.
I have tried to read around but havn't found any articles that really solve my problem. Most say something about not having my annotations/mappings not configured correctly. But I can dump the entity manager through a controller.
var_dump($this->getServiceLocator()->get('doctrine.entitymanager.orm_default'));
What do I need to do to get this to generate entities from xml mappings? Any help is appreciated.
I had a similar problem with YAML files and posted my solution here. I'm sure this will work with xml files as well. Just try to add
$driverImpl = new \Doctrine\ORM\Mapping\Driver\XmlDriver(array("YOUR_PATH_TO_XML_FILES"));
/* #var $em \Doctrine\ORM\EntityManager */
$em = $application->getServiceManager()->get('doctrine.entitymanager.orm_default');
$em->getConfiguration()->setMetadataDriverImpl($driverImpl);
to the doctrine-module.php.
Did you try using the doctrine-module script in vendor/bin? It should be all set up already to read your app's configs.
./doctrine-module orm:generate-entities ~/doctrine-entities
This "error" occured because you use Annotation Driver for generating. This driver uses your current exist entities and doesnt look at xml. If you want to create Entities from XML - you should send to DI in doctrine configuration section XML driver with need path.
I use another zf2 doctrine module and my DI config has another format, so i cant to send you properly DI example.
Using ext/ldap I'm trying to add entries to an Active Directory. As long as I only use one single structural objectClass everything works as expected, but as soon as I try to add an entry with a second auxiliary objectClass, the server reports an error:
Server is unwilling to perform; 00002040: SvcErr: DSID-030F0AA0,
problem 5003 (WILL_NOT_PERFORM), data
0
The following code works:
ldap_add($ldap, 'OU=Test,OU=Test,DC=domain,DC=example,DC=local', array(
'ou' => 'Test',
'objectClass' => 'organizationalUnit',
'l' => 'location'
));
This doesn't:
ldap_add($ldap, 'OU=Test,OU=Test,DC=domain,DC=example,DC=local', array(
'ou' => 'Test',
'associatedDomain' => 'domain',
'objectClass' => array('organizationalUnit', 'domainRelatedObject'),
'l' => 'location'
));
The same happens if I try to add an auxiliary objectClass to an existing entry:
ldap_mod_add($ldap, 'OU=Test,OU=Test,DC=domain,DC=example,DC=local', array(
'associatedDomain' => 'domain',
'objectClass' => 'domainRelatedObject'
));
The corresponding error message is essentially the same
Server is unwilling to perform;
00002040: SvcErr: DSID-030508F8,
problem 5003 (WILL_NOT_PERFORM), data
0
As all other updating and adding operations work, I think the problem must be related to the objectClass attribute.
As I've not enough experience with Active Directories (I'm used to OpenLDAP):
Are there any known issues with objectClasses in Active Directory? Am I missing something here? Are there any restrictions that disallow adding e.g. domainRelatedObject to an organizationalUnit? What the heck 's going on here ;-)?
Just in case you're wondering: the domainRelatedObject is present in the Active Directory schema.
I just found that, in order to add dynamic (per-instance) aux classes, the forest functional level of the domain must be 2003.
You may not have permission to set the objectClass attribute. See whether you can attach the auxiliary class after creation, through ADSI Edit. If you can't, fix the permissions first (check the Properties tab in the Advanced view of Security settings)
I could attach this specific class right now, onto a organizationalUnit object, as a domain admin; so in principle, this is possible.