I am shifting this to a real meta issue about the Drupal 8 version, further discussion should happen in sub-issues. I have made an initial commit for Drupal 8 and cut a development release. Here is a transcript of the release notes:


Development release for Adpativetheme Drupal 8.

The D8 version of Adaptivetheme is a total re-write of the core theme and sub-themes. The admin theme has been removed also.

You MUST enable AT Core first

This theme uses PHP Classes and autoloading, however that will fail in Drupal 8 if the base theme is not enabled. If you enable a sub-theme without first enabling AT Core you will get a fatal error. At the moment this is a limitation of Drupal 8, hopefully by the time Drupal 8 ships sub-themes will be able to force base themes to be a dependancy, but right now we cannot.

I'm hoping like hell this beta blocking critical issue will fix this problem and we can all sleep easier: #1067408: Themes need an installation status

Everything is treated as a Block

NOTE: this current version anticipates the commit to Drupal 8 of the "convert everything to a block" patches. This means that if you enable this theme you will not see things like the Logo, Site name or slogan, Page titles, Tabs, Actions links etc etc. The one page level variable I have included as a legacy support feature is the Messages variable, because we really need that during development. When the D8 patches are finally committed this will be removed.

I have created this module to use for testing: https://drupal.org/sandbox/jmburnz/2122067 it includes page title, site name, slogan, logo, messages and action links as blocks.

Please see these issues and help out if you can:

#1053648: Convert site elements (site name, slogan, site logo) into blocks
#1869476: Convert global menus (primary links, secondary links) into blocks
#507488: Convert page elements (title, tabs, actions, messages) into blocks

Drupal 8 will ship block configuration files in the themes config directory - this will tell Drupal to enable certain blocks when the theme is enabled. Currently there are patches against Drupal 8 for Bartik to achieve this, and Adpativetheme will of course do the same.

Its still early days for Drupal 8, we are still many months away from release so we have a lot of time to discuss and expand, develop and hone the ideas presented in this theme - they are radical and far reaching, I make no apologies for that. Time to move forward with new ideas about how we can improve theme building, how we can make theme building faster and easier.


AT Core:

The core theme provides just one front facing capability - a sub-theme generator that you can use to create new sub-themes. Enable the AT Core theme and visit it's setting page to generate a new sub-theme. There are two sub-theme types - a minimal sub-theme and a standard sub-theme. Documentation in included within the AT Core Appearance settings under the Help tab.

I would like to personally thank kingfisher64 for making this feature request and inspiring the development of the sub-theme generator, I hope new Drupal users find this easy to use (it is). It really does take the difficulties out of creating new themes.

The long term goal is to replicate these options in Drush, which is a high priority.


AT Sub-themes:

The biggest change for sub-themes a complete new layout system and does not include a GUI for manipulating layout values, instead you can select precomposed layouts or build your own. A "layout" is akin to a layout plugin however they have no templates. Page template code and region declarations are generated from definitions in the layouts yml file.

There is extensive help included within the theme itself. All sub-themes have a Help tab with many pages of help on the various new systems within the theme.

The primary reason for these changes is to allow themers much more control over their layout, and for me to be able to provide many more layouts well beyond what the AT7 version was ever able to support (mainly due to the complexity of the old AT D7 page layout plugins). The new layout plugins are extremely simple, and while they require you to provide the CSS layout there are many more options for doing so.


UI Kit:

A fundamental change in FD8 will be the addition of a UI Kit - the early versions have been committed. The basic idea here is to ship (optional) extensive list of SASS partials that speed up theme development, some have JavaScript helpers (such as mobile menu toggle type script for navbar menu styles), but there is big focus on CSS3.

The JavaScript ships as libraries in AT Core, so these will turn on automatically if you include the optional UI Kit when you generate a sub-theme. All of them will be very small, a few kilobytes, there will be no major JS features, its all going to be heavy focus on things like CSS3 :target, transitions and transforms etc.

UI Kit based themes will have a fairly distinct aesthetic design out of the box, however because of the extensive use of SASS variables and the overall structure of the files and variables you can change this very easily and quickly.

Right now the UI Kit is in development/prototyping stage.


Extensions:

Extensions have been added back in:

  • Fonts
  • Images alignment and captions
  • Touch Icons
  • Markup overrides (varying options, mostly the same)

Fonts will undergo a major re-write to simplify all aspects, including a new, easier way to add Google fonts and likely deprecate support for @font-your-face since this was the least used feature of the fonts system.

Image alignment and captions can now be configured per content type and per display mode - so you have very granular control over image field alignment.

Touch icons is the same.

Markup overrides is pretty much the same although don't expect everything to work at this stage :)

In the first commit all extensions have been removed. This is pending a full review of all extensions, how they are being used by real users, and what might be applicable to D8. For example some extensions may be removed because D8 now supports the option natively, or that a module has risen to prominence that can now be relied on to provide the same capability without overloading the theme with features and code. It is highly likely that a large number of extensions will be shipped with the theme, however it is not yet decided how this will work or which ones these will be, most likely to be included are the Fonts extensions, Title styles and something similar to the Image Alignment and Captions extensions. Some of the Markup Overrides will make it but some will be removed simply because the theme works differently now and some we don't need anymore due to D8 changes.


Code Reviews and Testing:

Really what we need are user tests and deep code reviews.

Testing: on all levels from all types of users. Where do you get stuck, what is hard to understand, hard to use? Are there concepts or features that are conceptually hard to or worse impossible to understand? What is your overall feeling towards the new system?

Code Reviews: many new ideas are being introduced here and I will not hide the fact this is my first real crack and doing Object Orientated PHP. There are some new classes and I have tried to understand the usage of classical patterns and leverage Drupal core where applicable. I would surely appreciate deep code reviews, ideas and improvements from experienced OO developers and patches are of course very welcome. I am looking for constructive criticism and ways to improve the code, performance of the code, extensibility and probably some more abstraction where that might make sense.

CSS and SASS reviews are also welcome. In particular if you use Susy Next (which all the shipped layouts and the new ELF layout system uses).

Comments

Short answer is yes. What I haven't decided on, as yet, is what form it will take - this depends entirely on D8 itself and where it ends up. I think we're at a point now (with D8) to really start planning where we can take AT, since D8 is so entirely different from D7 I had to wait until now to get a very clear picture of how a theme will work and what sorts of cool stuff we can achieve.

What I will do is create a new 'version' in GIT and start mapping out features and discussing these with the community.

Superb. If there's anything I can do (that a non developer) could contribute, eg, create an AT demo site, bug testing, trying out patches etc let me know, i'd be glad to help if I can.

I think AT is hands down the best Drupal theme, really 8 would benefit greatly if it came shipped with it by default.

Title:Drupal 8Drupal 8 - what do we want, not want, and what sucks about the D7 version of Adaptivetheme

OK, I have kind of hijacked the thread so we can use this for a bit of a discussion about the Drupal 8 version - I made some notes how to contribute as a non-programmer.

Possible feature suggestions for d8 version, please shout "they suck" if they truly do

  • a backend UI that allows the user to be able to create subthemes. This was mentioned in #drupal the other week by someone when I suggested they look at AT. (maybe this functionality would be good for Premium themes?)
  • my suggestion - to be able to save the state of an AT enabled theme. I ship all sites with AT but at present things like extensions enabled, markup overrides need to be re-configured on a new site setup each time. It would be great if AT was able to remember the config settings or had a way to import the correct preset for a site. The preset route would be flexible.

Possible feature suggestions for d8 version

  • a backend UI that allows the user to be able to create subthemes. This was mentioned in #drupal the other week by someone when I suggested they look at AT. (maybe this functionality would be good for Premium themes?)
  • to be able to save the state of an AT enabled theme. I ship all sites with AT but at present things like extensions enabled, markup overrides need to be re-configured on a new site setup each time. It would be great if AT was able to remember the config settings or had a way to import the correct preset for a site. The preset route would be flexible.
  • new suggestion
  • Being that the semantic code is becoming more and more important, built in support with either https://drupal.org/project/rdfx or https://drupal.org/project/microdata would be useful. In addition https://drupal.org/project/fences. Obviously this would be in whatever form these modules take in d8.

Fences will work for the most part afaikt, I have used it a lot in the past and found no real issues.

Generating a subtheme is an interesting idea, that I think could be done and would work pretty simply, I personally really like that and would use it - right now I tend to use the drush features and fix and repair when they go wrong (they need work).

The state of a subtheme is saved already, its captured in the [themename].info.txt file that is generated when you save the theme settings - there are quite a lot of instructions on how to use this to migrate a theme. Even your custom color scheme is saved if you are using a colorable theme like Corolla or one of the commercial themes. Now - this is where, for me at least, things start to get pear shaped in Drupal 8 - I want to use the configuration system to save things like this, but I am not entirely sure how to do it, the idea being that when you export and import your D8 config all the theme stuff goes along with it. I have to work on this.

Title:[META] Drupal 8 - Roadmap and UpdateDrupal 8 - what do we want, not want, and what sucks about the D7 version of Adaptivetheme

Updates:

Having spent the best part of a few weeks thinking about D8 and looking at potential ways we can do advanced themes I have come to some strong conclusions:

1) The initial commit is going to be a relatively simple theme with the vast majority of what you know to be "AT Core" removed. simple reason is D8 is still moving a lot, shifting sands so to speak, AT D8 is a ground up rebuild with all previous assumptions and ideas revised.

2) Heavy focus on external library integration. AKA the ability to load whatever lib you want, or piece of a lib, very easily.

3) Using Sass for building the layouts, most probably Susy Next, but you can use anything you want, i.e. use Bootstrap/Zurb Foundation/Zen Grids if thats what you prefer etc etc.

4) Tending towards not invented here (i.e. external library integrations made easy, make no assumptions), tending towards simplicity over complex solutions. Focus on 80/20 and you fix your own edge case.

5) Layout building is seriously revised, seriously. The big issue here is site builders vs hard core front end developers. Each party wants different tools, not easy to satisfy both, that is the hard bit here. I also have the issue of code maintenance and dev costs.

6) For the record AT will use Twig, just in case any one asks that question, Twig is too good to not use, and phptemplate to insecure in D8.

7) Subtheme generation is seriously on the cards, this will probably be a wizard, with similar or the same in a drush script also.

8) Likely to be very little in the way of theme_function or template overrides by default. Also the less we need to do in process functions the better, I really want to leverage the hell out of core and make very few theming assumptions. D8 is miles and miles better than D7 on many accounts, lets use it.

Thats about where I am at right now, the last few years have seen a revolution in how we build front ends, so time to drag this theme into the modern age, but still provide robust and flexible tools for site builders and hard core front enders.

I will commit the D8 branch in the coming weeks and then its all GO GO GO.

Title:Drupal 8 - what do we want, not want, and what sucks about the D7 version of Adaptivetheme[META] Drupal 8 - Roadmap and Update

Updating and repurposing the issue, initial dev is going well, still on track for a first commit next week.

Love the idea of being able to load whatever library is needed in each individual case.

Proposed enhancements to AT (not code based)

Have a AT theme upload section somewhere (I'd be wiling to setup a virtual server for you if it helps) where users of AT can upload their specific setup for others to view & download. Could be v useful if there are now going to be significantly different setups with libraries etc. I'm not clear on exactly the level of flexibility AT8 would have.

It would also be a way for AT to grab hold of the AT theme market as it would be no longer just download the theme and customize to your heart's content, but on top you would get contributions back. A place to go when a user has a specific project (eg, restaurant) they can have a look round and find a suitable theme. This might paint a picture of how people are using AT and help shape it's future direction.

So this doesn't step on the toes of your theme club, there could be further customizations available from the author? - for a fee.

Just throwing some ideas out there.

I have built about half the Libraries feature, I was thinking about relying on the Libraries module (Library API) but its doesn't really work how we need it to, in case anyone wonders that. I could use it, but it would mean themers will be confronted with everything in the libraries directory - that could mean WYSIWYG editor JS files etc etc, probably not what we want.

The libraries feature is pretty cool, I should have this in some sort of working order in the next week or two.

At moment I have been working on the Sub theme Generator - this work is pretty much complete for the time being. It works very well - there are three types of sub themes you can generate, and you can even select the base theme (in other words you can generate sub-sub themes, or even sub-sub-sub themes if you really want to).

There are few caveats at the moment for those sub-sub themes, but it does work and takes about a nano-second to generate a new theme. Hopefully I can iron out the caveats before D8 but really even as it is now its very usable and works a charm.

Regarding a Repo, well, you might know I have tried that before, about 3 years ago or more, and back then only one person contributed a theme. I think people are really busy and frankly Github is the king when it comes to forking and redistributing code, I would encourage people to use Github or even Drupal.org if they can get their project approved, I know that can be time consuming which is why I say go for Github if you just want to throw stuff out there and share.

Just for the record I will always encourage people to contribute back - I love the innovation factor, seeing what people do with stuff. Its often the highlight of my day when someone sends me a link and tells me what they have built with AT or another of my projects.

I guess if I had to put in my first-year-Drupaler two-bits I'd say:

* custom Gpanels (or comparable) would be good.
* Easy region definition
* Stability of the mobile-responsive features.
* Mobile menu in any region
* easier color integration (for the non-coders in the crowd)
* An AT forum for solutions rather than the issues queue (not your fault)
* A new D7 release before D8
* A solution to FOUT and an end to world hunger.

I still do CSS by hand, so I'm prolly in the dark ages with that one.

Mobile menu in any region means it should be a module, probably an addon to the the new Menu Block features in Drupal 8, as in a bit like a formatter for views but plugged into the actual block configuration, much like Superfish does right now in D7. That would be by far the best solution.

Easy region definitions, well, I am not really sure what is meant by that.

Gpanels - well, its likely the entire page will be built from Gpanel-ish chunks of layout that you can swap in and out as you need. It mostly works like this now but is a proof of concept stage of development. I have to wait to see what happens with the SCOTCH initiative. Changes will need to be done in code, personally I think this is the best solution, so the challenge becomes making that very easy.

Color module is a core module, we themers just have to work with its features, there is little to nothing I can do about this. What I can do, and have done, is make it trivial to sub-theme a colourable theme, you might be shocked in the D8 version of AT because you can clone a theme with a few clicks.

I should reiterate so people are not too shocked but the D8 version is going to be radically different. Times have changed in the past two to three years as have the demands of themers and site builders, Drupal is in a huge transitioning phase and the audience is changing. Before we could kind of get away with building highly proprietary solutions (like AT 7.x3.x and Omega 7.x-3.x also) but that window is closing and we need to find better, faster and more open solutions - and frankly that means putting some of the tricky stuff back into code (meaning you have to do some coding if you want to change stuff), and reducing the amount of pointy-clicky stuff because that constrains you to a set of options.

What I am gunning for this time around is finding the pain points for the REALLY hard stuff and make those things easy to achieve, as well as making things like layout pretty easy with a little elbow grease and the right documentation. I think there will be a pretty big focus on building helper modules also, such as a mobile menu block module, or something like that.

I'm not sure if prefixing & postfixing empty blocks will be part of scotch initiative, so I'll propose it as an idea.

It appears that drag n drop UI is going to have a high priority of emphasis. So with that in mind how about "designing/laying out" the design in AT8 in the front end?

From the front end being able to define white space equating to a % value. So in the header if I want the logo block to be 33.4% of the total header and placed in the middle I would apply a prefix of white space of 33.3% and a postfix of 33.3%.

Out of interest how will AT play with https://drupal.org/project/layout ?

Title:Drupal 8 - what do we want, not want, and what sucks about the D7 version of Adaptivetheme[META] Drupal 8 - Roadmap and Update

AT would have used Layout Module if it was in Drupal core, but it was removed. I tend to think that the general lack of interest in Layout module and clear signs this is not being heavily worked on could mean it's dead, we will have to wait and see, personally I had high hope for it but I can't honestly rely on it at the moment. I say it has a general lack of interest because despite huge efforts to promote it, lots of development and even a stint in Drupal core, after one year a mere 600 sites use it and most of them I bet are test sites and Simplytest.me sites, almost no work is being done it and all its important issues in Drupal core failed to attract much attention. I gotta listen to that.

Just to be clear, it was not the GUI in Layout Module that made me interested, it was the idea that themes declare "layouts" and a Layout module "layout" is a stand alone thing, like a layout plugin almost, so is highly reusable and not bound to one theme. That is what Drupal core like also and the only bit of Layout module that got committed was that. No GUI was ever included in Drupal core.

The current AT Core prototype uses yml files to define layouts - in short you write an info file and AT Core will generate the twig markup and save it (writes page.html.twg) using this layout.yml file. A theme can have many "layouts" and you can apply a layout to a path using template suggestions (AT Core generates these as well). Think of a "Layout" as kind of like a really simple plugin. In many ways its kind of like Layout Module, only different and probably more powerful.

The actual CSS is provided by the "layout" and you have to write this yourself (or use an existing layout or edit one manually). AT will ship with many tools to make this a fast and easy task, even for non themers, and of course front end developers they can use whatever SASS, LESS etc that they want. Basically you can get away with never writing any actual twig markup code or CSS if you don't want to.

I think Layout module had lots of promise, especially the version that was in Drupal 8 (which did not have a GUI), essentially I liked the idea that themes could declare "layouts" and these were just simple code. I believe that SCOTCH was to provide a way to "attach" a "layout" to a "path" (eg the front page) and you could set blocks just for that one instance of the layout, I was never totally clear on what the plan was for that part of the SCOTCH initiative. Anyway most of those issues are bumped to Drupal 9.

Its some of those ideas I've taken and melded into the new theme, being about the declare and define "layouts" and create templates suggestions (paths).

So to answer your question directly no AT will not provide any sort of drag and drop layout builder etc etc, to my way of thinking those are solved problems in the real world of theme development, they are not an issue for me and most others either. The real pain points are in other places and I am focusing on the really hard problems we as theme developers face on a daily basis, for me that is time, how long it takes to do stuff.

As an update the theme is getting to a pretty high level now and probably time to start committing code - because of the rather cutting edge nature of this theme it needs to ship with documentation right from the start so I am writing that now. Thats actually the biggest pita for D8 right now - very few good docs have been written (there are some good ones, like CMI is well documented as is Tour module) and because AT D8 uses D8 centric ideas I will have to document them extremely well.

Really what I am designing and building here is an entire layout system that is compatible with everything else around it, say like Panels, it won't break basic functionality such as something like Omega 7.3 did (stripped away template suggestions as a goto tool) and forced you to use delta and context modules.

We don't want to go there - instead interoperability is paramount as is doing things the way front end developers (esp D8 themers) will likely work in D8 is really important - lots of crystal ball gazing here because D8 is still likely to be some time away and do no be surprised if things get ripped out (brutally so) as it depends a lot on what modules like Panels and Page Manager end up doing in D8. I would be watching that space very closely.

If all things work out equal and D8 ships essentially in its current state just finished and bug fixed, then we are on track.

Issue summary:View changes

update issue with details about reporting issues in D7 version etc

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

add section for reviews and code feedback

Issue summary:View changes

Updated issue summary. spelling error

I've made the first commit for D8.

You can download it here: https://drupal.org/node/2119327

Please read the release notes, its a good intro to the theme and includes some vital information for usage at this stage.

Its pretty raw and needs some work on the settings, to use it you should:

  1. enable AT Core
  2. then generate a new sub-theme (visit the settings page for AT Core and use the generator)
  3. enable the new sub-theme
  4. go to the new sub-themes settings page, select "default" from the Page Type setting, select a layout (probably Univer is a good choice) and save the config.

In the future you won't need the final step, but just right now I forgot to update the settings etc, so in a few days that should be fixed.

To compliment the new theme I have created a module that implements page and site elements as blocks, this module will follow the core patches:

https://drupal.org/sandbox/jmburnz/2122067

If anyone can't use git to grab this module let me know, I'll consider promoting it to a full project until the core issues are committed:

#507488: Convert page elements (title, tabs, actions, messages) into blocks
#1053648: Convert site elements (site name, slogan, site logo) into blocks

Issue tags:+atd8

tagging

Issue summary:View changes

add warning message about autoloading

Issue summary:View changes

Version:7.x-3.x-dev» 8.x-1.x-dev

Should be 8.x-1.x-dev?

Yes D8 indeed, I assume the "upgrade" has broken issues in many ways.

Issue summary:View changes

Issue summary:View changes

Issue summary:View changes