i think it would be great to split the module in two parts: the module that does the migration and the module that has to stay enabled after the migration is done. if i read the code correctly, the only part of the code that has to stay enabled after migration is the part thats mapping old urls to new urls. that could be exported to an extra module. or (if it is really the only thing thats needed after migrating) it could be implemented using the core drupal path alias feature.

CommentFileSizeAuthor
#7 dadaimcpath-6.x-1.0-dev.tar_.gz1.29 KBAnonymous (not verified)

Comments

Anonymous’s picture

i now discovered, you already use the path alias feature using $node->path. i first only saw the dadaimc2drupal_menu() stuff.

i wrote

  //objectid = dada objectid, type is dada type, nid is drupal node id, cid is drupal comment id
  function dadaimc2drupal_addpathalias($objectid, $type, $nid, $cid = NULL) {
      switch ($type) {
    case "article":
        path_set_alias('node/' . $nid, 'newswire/display/' . $objectid . '/index.php');
        break;
    case "feature":
        path_set_alias('node/' . $nid, 'feature/display/' . $objectid . '/index.php');
        break;
    case "otherpress":
        path_set_alias('node/' . $nid, 'mod/otherpress/display/' . $objectid . '.html');
        break;
    case "media":
        path_set_alias('node/' . $nid, 'media/all/display/'. $objectid . '/index.php');
        break;
    case "comment":
        path_set_alias('node/' . $nid . '#comment-' . $cid, 'mod/comments/display/' . $objectid);
        break;
      }
  }

i think html is the right extension for otherpress and for comments i don't know if there is one

jonhattan’s picture

The hook_menu() stuff is inherited from dadamigrate.

I've already added the primary node path (see saveNode() in base.batch.inc):

    // node path.
    switch ($type) {
      case 'Article': 
        $path = 'newswire/';
        break;
      case 'Feature':
        $path = 'feature/';
        break;
    }
    $path .= 'display/'.$row->objectid.'/index.php';

but this is ignored/overwriten if pathauto enabled during migration and probably I'll remove it.

Setting node aliases (my option or yours) is not as good as hook_menu() because those both are valid paths:

http://canarias.indymedia.org/newswire/display/19589/index.php
http://canarias.indymedia.org/newswire/display/19589

hook_menu() is able to manage both at once. I don't think adding the double of path aliases or aditional some apache rewrite rules make worth it.

There's also the SEO thing. I haven't seen what exactly does globalredirect or path_redirect modules but I think a redirect 301 instead of drupal_goto() is the way to better implement this.

I agree to split the module. Do you wanna work on a separate module with hook_menu()? Anyway I'm up to discuss other options.

jonhattan’s picture

Other thing to take into consideration is that the tables storing the map between dadaimc objectids and drupal ids are part of dadaimc2drupal ...
technically is not appropiate to make other module dependant on this tables if the module doesn't depend on the module responsible of the tables. If you disable and uninstall dadaimc2drupal the tables are deleted. A solution is to move the tables to the new module and define a hook to call after a node/tax,etc has been created. I mean to replace snippets like this:

        $record = array('objectid' => $row->objectid, 'nid' => $node->nid);
        drupal_write_record('dada_articles', $record);

to

  module_invoke_all('dadaimc_post_import_object', 'article', $row, $node);

and define something like this in the new module (dadapaths?):

  function dadapaths_dadaimc_post_import_object($type, $row, $node) {
     $record = array('objectid' => $row->objectid, 'nid' => $node->nid);
     drupal_write_record('dada_'.$type, $record);
}
Anonymous’s picture

you're right, using path_set_alias i cannot set the http response code. this is possilbe using drupal_goto, so maybe the hook_menu option using drupal_goto with 301 is a good solution.

i think the best way would be to use the path_redirect module. it makes 301 redirects. theres a diskussion about getting path_redirect into core (http://drupal.org/node/133552). the advantage of using path_redirect instead of hook_menu is that someone else is maintainig it.

jonhattan’s picture

Title: split the module » manage legacy paths

I was not aware of the option to set a response code for a drupal_goto(). Definitely I prefer hook_menu and drupal_goto.
For path_redirect (that will not be in core on the short/medium term) we need to sink the database with paths, and also there're at least two paths for each article (with and without index.php as I said in #2).

We should also take care of urls to multimedia as:

http://canarias.indymedia.org/usermedia/image/10/g8-torre.jpg

those must be redirected to sites/SITE_DIRECTORY/files/usermedia/image/10/g8-torre.jpg

typically SITE_DIRECTORY is `default` but it may change.

Anonymous’s picture

hm, but the redirection of multimedia only works with private download of files in drupal, is that right? at at.indy we use public download method (because of performance) so i would copy the usermedia file to the drupal root folder (or make filesystemhardlink to where the usermedia folder actually is) and don't change the path of the media files.

Anonymous’s picture

StatusFileSize
new1.29 KB

i wrote a dadaimcpath module. it creates a table where it saves the dada objectid, drupal nid, dada object type and if its a comment the drupal cid. it uses hook_menu and drupal_goto to redirect to the node.
to insert into the database:

dadaimcpath_insert($nid, $objectid, $cid = NULL, $type);

TODO: write a check, so it does only redirect in case of 'objectid/' and 'objectid/index.(php|html)' and not for example 'objectid/foobar'
TODO: check for private download method and if enabled, also redirect media files