0

Just transferred my brand new Drupal webshop to shared to host and guess what: it doesn't work.

I can't figure out that why node add page is lacking form? Everything else is in place. And to be more spefic it is just for one content type, other work fine.

I've tried drush rr, drush cc all etc. I've checked permissions etc. I'm using Display Suite forms as template for node add form.

This all of the rendered form markup that has a empty div container:

<form class="node-form node-content_type-form" enctype="multipart/form-data" action="/content_type" method="post" id="content-type-node-form" accept-charset="UTF-8" novalidate="novalidate"><div>    

    </div></form>

And this is for anonymous users. For admins it work normally but it also has another theme.

When I tranferred the site I took a archive dump with drush and imported it into shared host.

UPDATE

Like always this Drupal like problem seemed very odd. So I decided just to change the theme and see if it has any effect.

Using the base theme of my custom the form is rendered normally.

However, custom theme works just fine on my localhost so I can't tell what is the problem. Seems like a theme issue but on the other hand not.

UPDATE 2

Base theme showed some "new" errors on second load. These errors refer to a oooold theme and shows that Drupal is trying to use that tpl file. I assume that this is the core problem which causes different results depending on theme.

'/home/user/public_html/sites/all/themes/custom_boot/node-content_type-form.tpl.php

UPDATE 3

I found the old code that registered this "theme" or template and which is still somehow required/requested on page load:

function custom_boot_theme($existing, $type, $theme, $path){

    return array('node__content_type__form'=>
            array(
                'render element' => 'form',
                //'path' => drupal_get_path('theme', 'custom_boot') . '/templates',
                'template'=> 'content-type-node-form',
            'user_register_form'=>
            array(
                'render element' => 'form',
                //'path' => drupal_get_path('theme', 'custom_boot') . '/templates',
                'template'=> 'content-type-node-form',
            ),
        );
}

How could I undo this?

UPDATE 4

If I remove this old theme and run drush rr, it will give following error every time:

    The following theme is missing from the file system: <em class="placeholder">custom_boot</em>. For information about how to fix this, see <a                        [warning]
href="https://www.drupal.org/node/2487215">the documentation page</a>. bootstrap.inc:1128

Even though custom_boot is removed from system table by drush rr, it will still try to find some files related to this removed theme.

UPDATE 5 - FINDINGS AND POSSIBLE SOLUTIONS

First of all it seems that the problem is somehow in the current theme. What is it? I don't know.

Secondly, why does this site work perfectly on localhost but not on this live server? Could I make some changes to PHP ini settings that would "look through"/disregard the small hickup of missing theme? I don't understand that why localhost won't die on this missing theme problem...

UPDATE 6

Well, since I couldn't get a rid of I had to stick with it. I've just enabled this old theme but which I'm not using. Now the form shows but it is rendered with this old themes custom form template file described above.

BUT, as soon as I visit /admin/structure/types/manage/content-types/fields the form starts failing again. So Display Suite and old theme have some issues.

AND TO ADD, it is all the same if the content-type-node-form.tpl.php file has content or not: the form is rendered and I can put any code in there and it won't change or break anything.

8
  • I think it is cache issue. just clear the cache or for testing just disable "Cache pages for anonymous users" from the performance settings. Commented Oct 18, 2016 at 5:29
  • drush rr, drush cc all - not a cache issue. And so far cache has been disabled. Commented Oct 18, 2016 at 6:44
  • How could I undo this? Remove the implementation of the hook (remove the entire custom_boot_theme function) and clear the caches once more. Commented Oct 18, 2016 at 16:42
  • I forgot to mention that this code was already disabled i.e. commented out. But the things it did are still somewhere in the system. I understand that this registers so to say "hooks" and now they should be removed/unregistered (manually/db/etc). This should have been happened when code was commented or theme disabled but for some mysterious Drupal reason that didn't happen. Commented Oct 18, 2016 at 17:00
  • You should disable that theme before removing it. Now the database thinks it has an active theme and can't find it.
    – Kevin
    Commented Oct 18, 2016 at 22:54

1 Answer 1

0

Well, now I feel stupid. Eventually it seemed to be a file permissions related issue.

I took this https://www.drupal.org/node/244924 script and modified it per server spec.

After few trials it worked...It certainly didn't seem like a permissions related but maybe they cause various situations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.