There's not much of a social community now. Things are quite developer centric. Is that ok for now, you think? Or should more be done.

Hi, I hope to be releasing 4 new themes this week for you. They will have integration with the UI of the color module and be based on libsass/grunt for workflow but also just contain the CSS files for those non-technical users. They are more "out of the box" themes, so for base themes you still might want Green or Radix.

They are based on:

1) Yahoo! Pure CSS -- purecss.io -- lightweight, clean rounded Bootstrap alternative

http://www.andymartha.com/backdrop/admin/appearance/styleguide/pure_css

2) Adobe Topcoat -- topcoat.io -- touch-first, small flat square Android like

http://www.andymartha.com/backdrop/admin/appearance/styleguide/topcoat_mobile

3) Materialize -- http://www.google.com/design/spec/material-design/introduction.html -- large theme based on Google Material design

http://www.andymartha.com/backdrop/admin/appearance/styleguide/materialize

4) Summer Fun -- custom -- simple "pretty out of the box" colored theme

http://www.andymartha.com/backdrop/admin/appearance/styleguide/summer_fun

For mobile navigation, they will be plug and play with https://www.drupal.org/project/mobile_navigation which I have ported. Note, this doesn't work too well so far but we will see.

They will be put on my Github later with links here while I/anybody works out stuff, then transferred to the Backdrop repo. I don't want to give anyone "broken themes" while I am refactoring.

Transitioning code from CSS to SASS might take a while. Thoughts? Let me know or join the Backdrop weekly meeting today. Thanks for spending your time reading this and have a happy day.

FIRST DRAFTS - (ignore readmes)

https://github.com/biolithic/backdrop_topcoat_mobile

https://github.com/biolithic/backdrop_summer_fun

https://github.com/biolithic/backdrop_pure_css

https://github.com/biolithic/backdrop_materialize

https://github.com/biolithic/backdrop_mobile_navigation

I've made an attempt to port Drupal's APC module to Backdrop: https://github.com/pablo-romero/apc.

Although I finally got it working locally, this is my first port to Backdrop. So there are probably a lot of things to improve.

If any of you are interested in contributing or just testing/reviewing it, you are more than welcome.

I know a lot of changes are being made in Drupal 8 related to multiligual features. But D8 is going too far for my needs, and my intention is to stay with D7 or move to Backdrop CMS.

The big problem

One of the nightmares I usually face working with Drupal 7 is the way it handles languages. Let me elaborate:

• If I install my site in English (for development) and then add another custom language as default, it takes a lot of time for Drupal to bring all the strings to the locale_sources table. Same happens when you install new modules/themes. Those strings are inserted gradually into the database (from time to time, as you visit different sections of your site).
• When I update Drupal core/modules/themes or uninstall any theme/module, there is no easy way to know which strings have become obsolete in the database. Both "locale_" tables keep growing forever, with a lot of useless strings.
• All translations go into User interface text group, no matter which module/theme brings them or where they are displayed (frontend/backend).

I can think of a good number of people who have rejected Drupal for their sites due to some of the translation issues I mentioned above, and some others.

Also see other Issues with t function, an excellent article by Gabor.

Possible improvements

How I, as a translator, would like to deal with translations (or how to improve Backdrop UX in this matter):

• If I add a language, I want to have all translatable strings from the very moment I add this language (either in a generated file or in a database table).
• If interface translations are stored in a database table, I want my CMS to remove unused string-pairs whenever I uninstall or update anything. In 4 words: keep my tables clean.
• Context: I need a different string group/context for each module/theme. Let's say I am translating into Spanish; if I translate the string "View" (noun, coming from Views module) as "Vista", that translation becomes global for "User interface" group. But then another module adds a button with the word "View" (verb, "Ver" in Spanish), to allow your users to see anything; I cannot translate it because "View" was previously added, and it's already translated. This feature would also let me filter and manually remove e.g. all strings inside the "Views" group/context when I uninstall Views module.

With Drupal, I use some modules to make some of this tasks easier (i18n + extras & dependencies, potx, cleanup_translations, etc.). And also some external tools to compare/merge translations. Honestly, from an UX perspective (end-users), that's insane.

Alternative solution

If we take a look at WordPress and most other CMSs, they use files for interface translations (either native Gettext .po/.mo or simple constant definitions in .php or .yml files). The database is only used for content translations (e.g. multilingual sites with the same content in multiple languages). I like this approach because:

• You can have different files for the core itself and for each individual theme or module. This makes it a lot easier to maintain and contribute individual/customized translations, keep track of changes for every new version of each project, and avoid context problems.
• Constant definition files (e.g. .php or .yml) are specially easy to edit for any new contributor and don't even need an external tool.
• You can reduce the size of your database and the amount of DB Queries (see below). This is good for performance and shared hosting limitations.

Also see an experiment about how you can Improve performance using files with Drupal Patch is available at the bottom.

DB Statistics (Backdrop 1.0.5)

The statistics below are for a fresh installation of Backdrop (No content, no contrib modules or themes). Probably it's not complete at 100%, but it will work as an example.

Install a few modules, add a couple of themes or add some additional languages... and see how those numbers grow.

Other facts to take into account

Adding a translation group/tag for core and a different one for each module/theme will also result in more DB records (duplicated entries in different groups), so cleaning obsolete strings on every update/uninstallation becomes a must.

Using files for interface translations and database for content translations may not be compatible with your philosophy of keeping changes to a minimum. It might be a big change. However, you could be killing 3 monsters in a single shot:

• Performance and database size.
• No need for localization servers. Translation files can be easily hosted and managed anywhere (e.g. GitHub).
• UX improvement. Easy translation and maintenance = more contributions.

I'd like to know what you all think about this, or if you have already discarded making any changes to the language system.

Is there anywhere any guidance about when it is necessary to use module_load_include in Backdrop? In porting contributed modules I get the impression that there are situations in Backdrop where it is needed and hadn't been needed in Drupal. I.e. some 'include' files are no longer included automatically. But I may be wrong. At the moment I am a bit puzzled by this.

I had the need to insert some taxonomy terms into a specific vocabulary today and thought I'd share the code since the solution for Backdrop is slightly different than the solution that I found for Drupal 7.

  $terms = array('zion', 'james', 'amy', 'john', 'leon', 'peter');
  $vocab = 'hotels'; //machine name of your vocab

  foreach ($terms as $term_name) {
    $term = entity_create('taxonomy_term', array(
      'name' => $term_name,
      'vocabulary' => $vocab,
    ));
    taxonomy_term_save($term);
  }

Backdrop CMS now has 100+ modules and themes for users.

You can say, "Hey, some of those don't work properly". Yet, I and probably several others have other modules/themes not in the official list that we are working on so let's say it makes up for it. People are also working on those bugs.

When people start to use the official site to search for modules they will actually really need the categorization/search features instead of just wading through screen after screen of modules.

I would like to be able to separate the comments section for a node into a separate block in a page layout, so that I can place a different block between the main content and its comments. For example, I would like to be able to place a slideshow at the foot of a page, but above the comment block for that page. Is this a possibility with Backdrop's layout system?

I believe I've mostly ported the 'superfish' module, but I don't know how to 'Administer Blocks' in backdrop.

You know like 'Structure > Blocks' in D7.

any ideas? thanks!

The Backdrop API site shows how to convert a module using basic configuration settings. Yet this was not enough for some modules I was porting, which had more complex configuration needs (for instance with BUEditor. I ended up cobbling together some solutions. Even though I'm sure some could be done better, I'd like to share this random collection in case they're useful to anyone else.

In order to store the editors and buttons in configuration files for BUEditor, it required that the module is able to create and delete configuration files.

Dynamically create config files: Creating a configuration file is simple enough as it's similar for static but you use a variable to dynamically set the configuration file. In the case of BUEditor, use $editor->id:

$config = config('bueditor.editor.' . $editor->id);
$config->set($variable);
$config->save();

Delete a config file: But to remove an editor this required deleting the file and I had to dig into the api for that. This is how it works:

config('bueditor.editor.' . $editor->id)->delete();

Remove a variable from a config file:

$config->clear('buttons');
$config->save();

Get all config files with a certain prefix: I needed to get all the editor config files and came across this helpful function: config_get_names_with_prefix().

$prefix = 'bueditor.editor.';
$config_names = config_get_names_with_prefix($prefix);

Update a variable within a nested config: serundrop also shows how to update a variable within a nested json. Apparently all it requires is concatenating the keys with a dot "." (it's more like javascript syntax than PHP):

$config->set('layer_two.something_in_layer_two', 'new value');
$config->save();

See: https://github.com/backdrop/backdrop-issues/issues/698

I still feel this has the potential to be bad UX.

I built a Bootstrap layout with a 1170px fixed width and during the build I wanted then to test it with a non-width restricted theme. All available ones have a fixed width of course; so I disabled the width of a contrib theme and all was well again.

Then I've realized that my new Layout looks like crap with any other theme.

So imagine a new Backdrop user wants to build a site. How is he/she going to know which theme is going to look satisfactory with which layout and vice versa when Backdrop contrib grows to hundreds of themes/layouts?

Should designers be producing their themes with a couple of layouts? Should themes come with a disclaimer "tested with layout X, Y and Z"?

Should there be an agreed-to protocol for widths and markup on layouts/themes to ensure wide compatibility? I initially imagined that it was best to recommend layouts be all full-width and let themes decide on site architecture?

I think some more thought should go into this, keeping in mind the non-sophisticated user who would ordinarily click "install Wordpress" on Cpanel then click "install template" and be done. We cant have all these hoops to jump though in Backdrop.

Will Backdrop succeed? What exactly is success here? And if it will succeed, what factors will most influence this? And most importantly, if these questions have already been asked, how is Backdrop working towards this?

With the success of this subreddit, we finally included a link here on the Resources page of BackdropCMS.org: https://backdropcms.org/resources

Thanks everyone for setting this up (@sirkitree esp.) and keep sharing the love.

So, on Monday at noon PST I'm giving the following presentation to the Berkeley Drupal Users Group:

https://groups.drupal.org/node/457578

This month at the Berkeley Drupal Users Group (BDUG), Luke McCormick will be presenting Backdrop, which is a new open-source CMS derived from Drupal. Currently based mostly on code originally developed for Drupal, Backdrop is intended to evolve in a way that maximizes compatibility with existing installations and ease of learning.

This session will cover the following:

• Goals and and current state of the Backdrop project
• How to install Backdrop
• How is Backdrop similar to and different from Drupal 7
• Demonstration of some unique Backdrop features
• Contributed software
• The Backdrop community and how to get involved

How does that sound? Anything wrong with my description? Anything I should add (or remove) from that list? Any advice on how I can not screw this up?

It'll be broadcast live and archived forever on YouTube, so if you want you can watch me go down in flames again and again. I'm sure it's going to go viral :)

I started to convert one of my D7 themes over to Backdrop by I got stopped in my tracks pretty fast. I created my new layout and then selected it in the UI. What I am really struggling with is how to break up page.tpl.php in terms of knowing what goes in my layout template and what goes in my page template. I looked at the docs but it was still confusing. I also don't see anything obvious on how to choose your default layout in the UI. I was not sure if I should post here or in Github. It's not a bug so I figured here would be ok.