Remove random PHP function calls and logic (other than render() and hide()) from all core tpl.php files

Tentatively tagging this as Novice, as it's pretty much just a question of moving those PHP expressions to the relevant preprocessor function, assigning them to a variable, and then printing that in the template.

Did a full search on all of Drupal 8 and here's are a few common issues I found (in addition to what was specified in the OP:

• Many instances of the t() function
• forum-list.tpl.php, line 52 & 60: use of str_repeat
• Found the same rendering of the primary and secondary links through theme functions in Bartik

Disclosure, I'm don't theme for a living, but have had to for several D6 sites.

IMO there will probably be cases where we need to leave in some PHP logic until [insert name of future theme engine] will provide that logic for us. These include simple things like:

if ($var) { echo "<div id=\"thevar\">$var</div>"; }

to more complex things like

if (drupal_is_front_page()) { [print several variables here] } else { [print only one of those variables ] }

I guess it's still undecided what "complicated logic" is (from the issue summary), but it'd be great to define a few do-remove and don't-remove-yet examples, to see what to tackle in this issue.

One of the reasons for adding business logic to theme .tpl files is the lack of another point to insert the code. It is more than Drupal core, it is also add on modules where they make up their own system for changing stuff.

The "is front page" problem is one example. What if we could create a subtheme for the front page then specify the use in the theme configuration page? Move it out of code into the Admin interface. Also have an option to specify in modules and blocks that they work only on the front page.

There are add-on modules, themekey for instance, but they do not fit the flow of other admin pages. The theme settings page has the option to use a different theme for admin but not the front page. If you could build the option into the theme settings page, you could remove it from the themes.

drupal_is_front_page() can be assigned to a variable (like $is_front_page) and passed to templates as a variable if it's not already. if / else feels out of scope here unless there's a really bad example.

Agreed. And

if ($foo):
print $foo;
endif;

is fine too.

That's happening already:
http://drupalcode.org/project/drupal.git/blob/HEAD:/core/includes/theme....

$is_front is the variable to use instead of drupal_is_front_page().

Ok, so to clear up:

This issue should leave in place (for now) any PHP logic for decision and looping (in the form of if/then/else, switch/case, for/foreach (and what else?)) that will hopefully later on be replaced with their equivalents in Twig/other template engine.

Is this true? If so, what other kinds of PHP code should go untouched according to this issue?

Jumping on this one.

As I'm jumping through all the core modules and templates, I'm really not seeing much for PHPiz'ms with the exception of the system module. Although:
* I am noticing cases where a11y functionality tries to be applied, and as important as this may be, really feels out-of-place. and could be attached via an output plugin (once a new theme system is available).

* I am noticing cases where the module's own preprocessing tries to throw in tags to wrap the processed output --- which should also be removed or pushed into the template.

* I am finding it hard to determine what's appropriate and what's not:
For instance, the search module has two templates:
search.tpl.php and search-result.tpl.php. In the back of my head, these seem like legitimate templates, BUT.
To me, a search against the entire site, should return results which just execute a view mode of a given entity.
Then, additional information should be attached via display fields (like search score, etc) to the display mode. (This might be filable as an additional issue, and easier to tackle once a new themeing approach is locked-in).
It seems as if there are templates in places where they could likely be thrown out entirely.

* The hook_help functionality should be entirely gutted (is there already an issue for this?) or a better practice suggested. A great deal of HTML is just written straight into the hook_help, which doesn't ultimately make much sense.

* Why does maintenance page /error handling have to vary so drastically from normal page processing? I'm seeing THEME_preprocess_maintenance_page() having to call X_preprocess_html() first. Which also seems like a bad habit.

@wjaspers re HTML in data. Are you referring to HTML for structure or for presentation? HTML is used for both and sometimes people want to rip out the structural elements.

Re maintenance page. The page has to work with almost no modules and no theme. If it was the same as a normal page, it would not be readable during maintenance. What could be done is to use a standard page to generate a static HTML maintenance page for use when the site is broken. I do not know if there is a plan or an issue along that line. we already have modules generating and capturing standard pages for search, link checking, and a dozen other uses. Applying the same to the maintenance page should be easy.

Since Twig is now in core as the default theme engine and all core templates will eventually be refactored, it seems we could postpone this until we are finished with the Twig conversion.

Removing Novice tag

We haven't converted everything to Twig yet (see #1757550: [Meta] Convert core theme functions to Twig templates), but all the .tpl.php files are gone (other than a couple to make sure PHPTemplate still works for those that want it) and have been replaced with .html.twig files with no PHP.