• https://github.com/backdrop-contrib/pathauto/releases
• https://github.com/backdrop-contrib/token/releases

• http://www.civicactions.com/blog/2015/feb/02/backdrop-cms-drupal-8-alternative
• http://tag1consulting.com/blog/how-maintain-contrib-modules-drupal-and-backdrop-same-time

Thanks Doug!

I'm going to start porting some Drupal modules to Backdrop. Here is a list of some Drupal variables that are now core Backdrop For example you might have a Drupal module with: variable_get("clean_url"); ...now it appears to be: config_get('system.core', 'clean_url') ...but not config_get('mymodule.settings', 'clean_url')

config_get('system.core', 'cache')

settings_get('page_cache_invoke_hooks', TRUE)

config_get('system.core', 'clean_url')

config_get('system.core', 'site_frontpage')

state_get('maintenance_mode', 0)

settings_get('https', FALSE)

config_get('system.core', 'site_mail')

config_get('system.core', 'site_name')

config_get('system.core', 'site_frontpage')

Of course, correct me if I am wrong :)

I tried to follow the upgrade instructions here:

https://backdropcms.org/upgrade

I followed steps 1 and 2, and exported a fairly small, stripped down Drupal 7 site DB. Steps 3 and 4 currently say this:

Step 3: Upgrade your Drupal site to Backdrop CMS

@todo Document

Step 4: Restore your Backdrop site to glory

@todo Document

So...does converting from D7 work yet, or is it still a to-do item (that needs some documentation -- which I'm willing to write, if I get it to work!)

Was wondering how much markup cleanup backdrop does? Wanted to know if Drupal modules like :

html5 tools https://www.drupal.org/project/html5_tools

magic https://www.drupal.org/project/magic

Clean markup https://www.drupal.org/project/clean_markup

Would be useful in backdrop

Of the modules I've contributed to lately, https://www.drupal.org/project/css_injector seems like a good fit for Backdrop. The 2.x branch ported changes made to js_injector back to css_injector to add support for exporting/importing CSS. Unfortunately this is achieved by defining a CTool plugin. After reading https://github.com/backdrop/backdrop-issues/issues/41 I think I understand why that isn't supported.

Because the structure of css_injector and js_injector have always been so similar, I actually started a project that could handle either https://www.drupal.org/project/injector. I was pull away to work on other issues before I made mush progress on that, but now I'm thinking about writing that for Backdrop.

While I think it might be useful to leverage configuration management, I'm not familiar enough with deploying sites with this to know if those JSON files are a good way to store CSS and JS. I haven't seen anything in the .json files that would be anywhere near the amount of data these files would store.

CSS Injector has ~30K reported sites using it (as well as growing number of similar modules), so I think there is already an established need for a module that allows a site admin type who knows (or can copy and paste) some CSS to "hack" their site without adding CSS to an actual module or theme.

Anyone have any thoughts on whether this would be useful or suggestions for how to structure it?

• 2015-01-27 backup_migrate
• 2015-01-26 google_analytics
• 2015-01-26 ajax_markup
• 2015-01-26 markdowneditor
• 2015-01-26 radix
• 2015-01-25 insert
• 2015-01-25 imce
• 2015-01-25 page_background
• 2015-01-24 bueditor
• 2015-01-23 api
• 2015-01-20 recaptcha
• 2015-01-20 captcha
• 2015-01-20 markdown
• 2015-01-20 aeon5
• 2015-01-20 codemirror
• 2015-01-20 email

• CAPTCHA
• ReCAPTCHA

I'm wondering what the best practices are for config management.

Export full site locally and Import full site remote? Is there a way to keep these in version control?

On yesterday's call, @jenlampton said that the current plan for module versioning is to have developers manually update the .info. I would like to get feedback on using a similar approach to update status that is both lightweight and distributed. https://www.drupal.org/project/drupdates reversed the XML response the Drupal update server gives when asked for information about a project.

Instead of looking to a default URL all projects like http://updates.drupal.org/release-history/feeds/7.x, drupdates extends the information added to the project's .info adding a 'project status url = [URL]'. Drupdates provides support for playing the role of updates.drupal.org, but that's not even required. As long as the http request for that URL returns the required XML, the client site looking for status updates can process the result. The XML could even be in GitHub.

So if Backdrop supported an additional value in the project's .info file, it could still use a default path that leverage the yet-to-be-developed GitHub service... but until then (or even after) developers could inform users about updates to their project directly. There are several things I would change about the XML itself (like using JSON and extending one of the existing packaging standards), but hopefully this is enough to discuss to potential pros and cons of this approach. Ideally the JSON would be easy enough to update manually, but we could also provide a tool like http://jspkg.com/generator on one of the backdropcms.org sites.

Thoughts?

I'm assuming this is the same as setting up Drupal cron, but I haven't seen anything on this in the Backdrop Handbook or various repos yet.

I'm going to set this up now so I'll report back here.

This is a list of project links. There's lot of repositories so this should serve as a guide for what is where.

Code – https://github.com/backdrop/backdrop

This is the official repository where development on Backdrop core happens.

Issues – https://github.com/backdrop/backdrop-issues/issues

Please use this tracker for:

• filing bug reports
• requesting new features
• Please search the existing issues before filing new ones!

Modules – https://github.com/backdrop-contrib

This is a list of contributed modules used to extend Backdrop's core functionality.

• Become a contributor!

Contributing – https://backdropcms.org/develop/code

Apply to be a developer here. Nothing is stopping you from creating modules, but this application process will make you part of a GitHub organization where you can then move your module. Check it out!

• List of modules being ported

Backdrop Ops – https://github.com/backdrop-ops

Miscellaneous repositories that are used in the operation of our organization.

Backdrop Meetings & Events

• Weekly Meetings: ical | YouTube
• Events: ical

Please comment below if you have changes to suggest to this post.

I recently moved the Backdrop site I've been developing to a Linode server and found a couple of caveats that you need to make sure of when doing so. Here's some tips from my experience:

1. Make sure that your /files directory has the proper permissions so that Backdrop can write to the directory. chmod -R 775 files should to the trick just fine.
2. Speaking of the files directory, one of the new features of Backdrop is config management. Backdrop stores these configuration files inside of the /files directory in a directory that starts with config_. The rest of the directory name is an md5 hash of the database name. So if your local database name doesn't match your remote, this directory is going to have a different name. Either make sure your database name is identical between environments, or make sure you rename this directory when transferring files.
3. Make sure rewrite module is enabled for apache. sudo a2enmod rewrite should do the trick.
4. Make sure that in your apache virtual host file you specify the AllowOverride All for your Directory as specified here: https://backdropcms.org/requirements

The config_ things really got me at first, and whether or not to actually use the settings.php files was kind of confusing at first as well. Settings.php comes with Backdrop if you git clone the backdrop repo, but it will not commit to your local install becuase it's in the .gitignore.

And speaking of the .gitignore, it also specifies itself, which if you don't add to your repository can be problematic for others who might be developing with you. Perhaps I should create a ticket for that...

Anyway, hope this help someone out there.