Posted by bartl on Mon, Nov 25, 2024 - 12:27am --- Updated: Nov 25 '24 - 12:29am

I'm in the process of migrating a Drupal 7 site to Backdrop.

When I click on a navigation link to /node/add "Add content", I get the message:

You have not created any content types yet. Go to the content type creation page to add a new content type.

Excuse me? Not only are there the default node types "Page", "Article" etc. but there's also a custom node type made in Drupal 7.

Clearly something is broken. I wonder how to fix it?

 p.s. If I go directly to a creating page like /node/add/page, I can enter a new page, so it's not a permissions issue, as far as I can see.

 

Most helpful answers

Have you run the update.php

Have you run the update.php process yet at this point? I'm wondering if you are trying to use the site in a partially upgraded state, perhaps.

Comments

Mon, Nov 25, 2024 - 4:55am by laryn

Have you run the update.php process yet at this point? I'm wondering if you are trying to use the site in a partially upgraded state, perhaps.

Mon, Nov 25, 2024 - 5:42am by bartl

I think I found the culprit. As I'm running a multi-lingual site, the page is handles by i18n_node_add_page instead of node_add_page. And the former doesn't appear to be ported to Backdrop. This is the code of i18n_node_add_page:

<?php
function i18n_node_add_page() {
    $item = menu_get_item();
    $content = system_admin_menu_block($item);
// ;...;
}

This is the only place left in the entire Backdrop codebase that uses this approach, apart from a few places in system.admin.inc. system_admin_menu_block is a function that looks up the system menu plus routes for thethe administration backend in the databse. And that returns an empty array.

This is what node_add_page looks like:

<?php
function node_add_page() {
  $content = array();
  // Only use node types to which the user has access.
  foreach (node_type_get_types() as $node_type) {
    if (node_access('create', $node_type->type)) {
      $href_url_friendly = str_replace('_', '-', $node_type->type);
      $content[$node_type->type] = array(
        'title' => t($node_type->name),
        'href'=>'node/add/' . $href_url_friendly,
        'localized_options' => array('html' => FALSE),
        'description' => t($node_type->description),
      );
    }
  }
// ...
}

and this is how it looked in Drupal 7:

<?php
 function node_add_page() {
  $item = menu_get_item();
  $content = system_admin_menu_block($item);
  // ...
}

That looks oddly familiar.

If I replace the codde of i18n_node_add_page with the new code opf node_add_page. the page just works. Perhaps it needs a few more tweaks, but the titles are translated and everything. I'm not even sure why i18n_node_add_page contained pretty much a copy of node_add_page, perhaps it should just point to node_adD_page instead, but I couldn't get that to worke because the source file from node that contains the function wasn't loaded.

Mon, Nov 25, 2024 - 5:43am by bartl

I think I found the culprit. As I'm running a multi-lingual site, the page is handles by i18n_node_add_page instead of node_add_page. And the former doesn't appear to be ported to Backdrop. This is the code of i18n_node_add_page:

<?php
function i18n_node_add_page() {
    $item = menu_get_item();
    $content = system_admin_menu_block($item);
// ;...;
}

This is the only place left in the entire Backdrop codebase that uses this approach, apart from a few places in system.admin.inc. system_admin_menu_block is a function that looks up the system menu plus routes for thethe administration backend in the databse. And that returns an empty array.

This is what node_add_page looks like:

<?php
function node_add_page() {
  $content = array();
  // Only use node types to which the user has access.
  foreach (node_type_get_types() as $node_type) {
    if (node_access('create', $node_type->type)) {
      $href_url_friendly = str_replace('_', '-', $node_type->type);
      $content[$node_type->type] = array(
        'title' => t($node_type->name),
        'href'=>'node/add/' . $href_url_friendly,
        'localized_options' => array('html' => FALSE),
        'description' => t($node_type->description),
      );
    }
  }
// ...
}

and this is how it looked in Drupal 7:

<?php
 function node_add_page() {
  $item = menu_get_item();
  $content = system_admin_menu_block($item);
  // ...
}

That looks oddly familiar.

If I replace the codde of i18n_node_add_page with the new code opf node_add_page. the page just works. Perhaps it needs a few more tweaks, but the titles are translated and everything.

Mon, Nov 25, 2024 - 7:03am by argiepiano

Forgive me is this is very obvious, but... have you enabled the module i18n_node? When you enable the module, it will replace the callback for node/add with the correct callback for i18n_node_add_page().

That module is found as part of Internationalization in Backdrop, but you have to expressly enable it.

Wed, Nov 27, 2024 - 4:19am by bartl

Yes of course I have, or i18n_node_add_pag wouldn't even be called. The problem is that it returns empty content.

Originally node_add_page and i18n_node_add page looked a lot more alike. node_add_page has completely been overhauled, while i18n_node_add_page is still pretty much the old drupal code.

I've tried it on a fresh Backdrop install, adding a new content type and all that, and there everything works fine.

i18n_node_add_page gets its content from the database, while node_add_page gets it from the json files in the config directory. And I think that in case of a migration directly from Drupal 7, there are gaps in the data in the system table in the database. Gaps that aren't there in case of a fresh Backdrop install.

Wed, Nov 27, 2024 - 7:31am by argiepiano

One more thing: have you check the site's log for any warnings or errors? If so, post them here too.