Drupal node add form is empty: why? 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:

&lt;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"&gt;&lt;div&gt;    

    &lt;/div&gt;&lt;/form&gt;


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'=&gt;
            array(
                'render element' =&gt; 'form',
                //'path' =&gt; drupal_get_path('theme', 'custom_boot') . '/templates',
                'template'=&gt; 'content-type-node-form',
            'user_register_form'=&gt;
            array(
                'render element' =&gt; 'form',
                //'path' =&gt; drupal_get_path('theme', 'custom_boot') . '/templates',
                'template'=&gt; '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: &lt;em class="placeholder"&gt;custom_boot&lt;/em&gt;. For information about how to fix this, see &lt;a                        [warning]
href="https://www.drupal.org/node/2487215"&gt;the documentation page&lt;/a&gt;. 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.
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.