backdrop-ops / backdropcms.org Goto Github PK

Consider adding http://fitvidsjs.com/ to make embedded video responsive http://backdropcms.org/develop/pull-requests

We need Travis CI to fail a pull requests immediately if the commit message doesn't start with "Issue #X:".

This will not only enable the automatic-comment to be created in the referenced issue, but also help our maintainers be able to merge pull requests without having to create new branches just to fix the commit messages.

Our paser (as mentioned in #4) just has to look for the sring "Issue #" as the first 7 characters to match.

The 'create a new theme for Backdrop CMS' URL in the first bullet point of the Upgrade page is incorrect - it has an extra 'l' that shouldn't be there: https://api.backdropcms.org/lthemes

Just did my first theme conversion of the Clean theme https://www.drupal.org/project/clean_theme. See it here at http://wilmurt.com/
There are a few things which need to be mentioned for persons hoping to do that as I'm sure you know. These were my personal thoughts:

• Overall it wasnt terribly difficult at all
• $block_html_id is not found but not documented as missing
• $attributes and $classes need wrapping in backdrop_attributes() and implode() respectively
• The main system menu doesnt have a <nav> tag
• The site name in the header somehow is wrapped in <h1> on the front page but <strong> elsewhere
• Comments on by default on basic page; it should be off I think
• Template documentation blocks need the available variables corrected. Example $picture is not available but is still documented.
• Most important, on creating a new layout, the content panel cant be found.

Clean came with a slider on the front page which is baked into the page.tpl.php. Since this template is now individual layout files, how does a them provide a slider now? Override layout templates? Provide a layout-front-page.tpl.php? This was a head-scratcher, which I still havent figured.

Finally if I wanted to list this theme on BD contrib page, whats the procedure?

I will try to put these thought into a coherent document eventually, but just wanted to record this here to highlight the issues.

The updated https://github.com/backdrop-ops/contrib reads well, but the "or later" license is now only used in reference to Backdrop itself and "additional code, libraries, images, fonts or other assets". I don't think it's clear that any module or theme code committed to Backdrop Contributed Project Group must be licensed as GPLv2 or later vs. just GPLv2.

You want both Backdrop core and contrib to have the option of being distributed GPLv3, right? Getting the "or latter" right is really important for both future compatibility and allowing distributions that include code with licenses only compatible with GPLv3 today.

The way Drupal.org can make the statement that "everything downloaded from Drupal.org is GPLv2 or GPLv2 compatible" while still being able to offer Drupal distributions as GPLv3 is through https://www.drupal.org/git-repository-usage-policy. Everyone who has committed code to CVS and GIT has agreed to the GPLv2 or later licensing policy. The packaging script running on Drupal.org includes only adds the GPLv2 license so what we've downloaded from Drupal.org is really only licensed as GPLv2 with the option of distributing it under GPLv3 if it was hosted somewhere other than Drupal.org.

A big reason to get this right is that GPLv3 isn't actually compatible with GPLv2.

https://www.gnu.org/philosophy/license-list.html#GNUGPL

"Please note that GPLv3 is not compatible with GPLv2 by itself. However, most software released under GPLv2 allows you to use the terms of later versions of the GPL as well."

I know. WTF?!? But in order to distribute contributed modules with Backdrop and additional Apache2 or AGPLv3 code, everything must be be GPLv2 or later... not strictly GPLv2. It's also worth reading http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#VersionTwoOrLater

By requiring users to agree to a GPLv2 or later policy when joining the Backdrop Contributed Project Group, you are achieving the same thing Drupal has with their Git Usage Policy. While neither project can control how users license this code outside of specific repositories they control (I can legally make my fork of Drupal or Backdrop GPLv3), the GPLv2 or later requirement as a policy is a powerful tool. I avoids having to go back to every contributor if you ever wanted to move Backdrop and all of the modules and themes in the Backdrop Contributed Project Group to GPLv3 in the future and keeps contrib compatible with other popular open source licenses for specific distributions.

@quicksketch in backdrop-ops/contrib#2 (comment)

This would be for a module that had a 2.x release:

# Checkout from drupal.org:
git clone --branch 7.x-2.x http://git.drupal.org/project/[project_name].git
cd [project_name]

# Rename the branch.
git branch -m 7.x-2.x 1.x-2.x

# Remove the old origin and point at Github instead.
git remote remove origin
git remote add origin [email protected]:backdrop-contrib/[project_name].git

# Push to the new repository.
git push origin 1.x-2.x

I don't think we have process documented currently, that's on us. We should probably add this to the converting modules section in https://api.backdropcms.org/node/28621.

I was interested in the concept of Backdrop from the start, but I am not sure how to contribute. GitHub seems (to me) to be a place for code, not community, and I notice that most open source projects pride themselves on a 'thriving community'. Is it too early to start Backdrop Forums?

Options for places to have a forum

Working on change records for layouts.module, it occured to me that there is a blur between change records and proper documentation for new stuff. Layouts in particular needs more than a "what changed", we need a whole lecture series (not really).
And when new users (non-ex-Drupalers) show up and need info about general stuff (how to...) we shouldnt be pointing them to Drupal.org?!
But we don't have a place for that yet do we?

We're going to run into problems with people filing PRs against the 1.x branch of backdrop for bugfixes (which should go into point releases) instead of 1.0.x

If a PR references an issue that has the label of bug, we should add a comment to the PR as follows...

Thank you for helping us fix bugs in Backdrop!  Bug fixes go into point releases, so please make sure your PR is against a branch for a specific minor version (1.0.x) as opposed to the branch for the major version (1.x)

It would be even better if we could determine the branch the PR was filed against and close the PR immediately (or maybe mark it Needs Work) if it wasn't the correct one.

http://backdropcms.org/guide/requirements

...
error_page 404 = @drupal;
 }
 location @backdrop {
...

During the three days at Drupal Camp Essen last weekend I had great discussions about Backdrop and Drupal 8 and the current state of Drupal 6 and 7 with people like dawehner, horncologne, webflo and others.

To my surprise it turned out in my Backdrop session that Drupal's backport policy is the biggest concern. A significant part of the audience was not even aware of that policy and some were shocked by it. Some who know me and my work on a stabilized Drupal 6 core came up with a great idea.

At the moment there are a lot of bugs in Drupal 6 and 7, the systems they use in production. For many of these issues there are existing patches. Some patches are already pending for a very long time because they are blocked by the combination of the current focus on Drupal 8 development and Drupal's backport policy.

Due to the fact that we stay with the "old" technology we will have to fix all these bugs within Backdrop sooner or later, too. If we take that into account we should consider a different approach for Backdrop 1.x:

Backdrop 1.0 should be released as soon as possible. But the base of Backdrop 1.x has to be the current Drupal 7.x instead of Drupal 8.x excluding Symfony.
The later will be kept as Backdrop 2.x without any changes to our current development process.

Using this approach we can start applying bugfixes from the drupal.org issue queue targeting Drupal 7.x to Backdrop 1.x and porting them forward to Backdrop 2.x as promised on backdropcms.org.

This way Backdrop 1.x will become a stabilized fork of Drupal 7 that is 100% API compatible to Drupal 7.x. People can use it right now in combination with all existing 7.x contrib modules. This will attract more users and developers to Backdrop. As soon as Drupal 8 and its contrib modules are ready they have the freedom of choice to switch back to Drupal 8 or stay with Backdrop 1.x and move forward to Backdrop 2.x when it's ready.

I assume that this approach won't cause too much additional effort and will help us to stabilize the new Backdrop 2.x as well.

In backdrop/backdrop-issues#81, we made our first significant API change. Changes like this need to be documented for those upgrading from previous versions of the system.

Unlike the handbook which is curated, I think we should reduce the barrier for change notices and just use our good-ol' node-based system.

Similar to documenting sub-systems, this would make sense to have changelogs documented on api.backdropcms.org, rather than the main site.

Contact page has access denied for anonymous user on https://backdropcms.org/contact

https://backdropcms.org/guide/modules

Upload the module to your site.

• Move the extracted files to your web server. You can do this using FTP, but we highly recommend using Git.

This would be better:

Upload the module to your site.

• Move the extracted folder into the modules directory in your site root. You can do this using FTP, but we highly recommend using Git.

Or like the theme instructions (but I think this is confusing for noobs)

Upload the module to your site.

• FTP/Copy/SCP/Git pull the extracted folder into the modules directory in your site root.

Regards
Geoff

URL is: https://backdropcms.org/coding-standards/doxygen
Should be: https://backdropcms.org/develop/doc-standards

See: https://backdropcms.org/develop/js-standards#comments

Since Backdrop won't work easily with Simplytest.me, and since we're on a platform that enables this more easily than before, we should look into building an automated sandbox environment for each pull request, similar to Lullabot's setup: http://www.lullabot.com/blog/article/github-pull-request-builder-drupal

However that might be a bit too liberal, we should expect hundreds of pull requests to be open at all times, which could cause some scalability issues. If possible, maybe we could make it optional if a sandbox were needed somehow, like assigning a label on the associated issue. Note that since pull requests aren't in the "issues" repository, we can't assign labels to them.

In order to get Backdrop listed as a github service (so that contrib module/theme authors can register their github projects as Backdrop extensions) we'll need to write our own code for it.

Here's the repo:
https://github.com/github/github-services

Here's the documentation:
https://github.com/github/github-services/blob/master/CONTRIBUTING.md

Right now we're using Github for project management. A limitation of Github's project management tools is that only contributors with PUSH access to a repository can label and organize issues. Obviously we can't grant everyone direct access to push to the main repository, given the potential for breaking tests and cowboy coding. So for now we've split the code repositories from the issue repositories:

https://github.com/backdrop/backdrop
https://github.com/backdrop/backdrop-issues
https://github.com/backdrop/backdropcms.org
https://github.com/backdrop/backdropcms.org-issues

We've made a Github team for "Documentation and Organization" that has push access to the *-issues repositories. Anyone should be able to join this team without the manual intervention of a human. I see this as happening in one of two ways:

• Anyone who submits a pull request is automatically added to the docs/org team.
• We also provide a form or button or something to enroll them in the docs/org team.

This may end up being a short-term solution only, if we switch to a different, permanent issue tracker that is not hosted on Github, see #2.

Someone wants to help me with an issue I am working on, and they do not yet have a fork of backdrop. They fork my fork.

The pull request I was working on (on the branch they forked) needs to have a comment added automatically notifying me that someone else is working on the same issue.

"@whoever has forked your fork and may be working on this issue as well: link"

Can we figure a way so that people can be informed of new additions to https://github.com/backdrop-contrib please?

As I mentioned previously, I think now that layouts (regions) are separate from themes, there should be a greater distinction between design (themes), layouts and functionality (modules).

A lot of people porting themes from Drupal to Backdrop are going to miss having theme-specific regions and are likely to bundle a custom layout with their theme. This, I believe, is currently supported and recommended, however I'd like to challenge this thinking with a slightly different proposal...

Say we have a Drupal theme (or WordPress theme) that has a specific colour-scheme, layout, font, slider, etc. and we want to port this to Backdrop. I recommend creating a:

1. Theme (with the appropriate colour-scheme, font, etc.)
2. Layout (with the necessary regions, etc.)
3. Module (with the code for the slider, if a compatible one doesn't already exist)

All of these should be available to download separately (since you won't always want the slider with the layout, or the layout with the theme), and then (to provide a Backdrop-equivalent of the Drupal/WordPress theme) a fourth download would package together the other three: theme, layout & module.

This fourth download would be kind of like a Drupal distribution, except without core, install profiles, etc. I'd like to tentatively name this type of download a 'package'.

To reiterate, if someone wanted to make a Backdrop theme with specific regions, they'd make a Theme, make a Layout, and provide both together as a Package.

I added twinz.gr + our logo (got a message about success too), but it is not showing up with the rest of the supporters. Does it need to be moderated/approved first or a bug perhaps?

On the page https://backdropcms.org/presskit, the link in the text "For more variations on the Backdrop logo and mascot, please download our Presskit." is currently broken. It points to https://backdropcms.org/files/book/Backdrop-Presskit.zip, which results in Page not Found.

With the imminent release of Backdrop 1.0.0 we should also move the official website to Backdrop to demonstrate that we have confidence on the release.

The following are things that need to be done as part of the port to Backdrop CMS:

contrib modules (moved into Backdrop core):

• admin_menu (since Backdrop 1.0.0 | #189)
• ctools (since Backdrop 1.0.0 | #136, #138)
• views (since Backdrop 1.0.0 | #40)

contrib modules (we need to port):

• codefilter | https://www.drupal.org/project/codefilter
• devel | https://www.drupal.org/project/devel
• formblock | https://www.drupal.org/project/formblock
• link #240 (target for Backdrop core 1.2.0) | https://www.drupal.org/project/link
• on_the_web | https://www.drupal.org/project/on_the_web
• redirect | https://www.drupal.org/project/redirect
• special_menu_items | https://www.drupal.org/project/special_menu_items

contrib modules (we can launch w/o these)

• honeypot
• search_config
• googleanalytics | https://www.drupal.org/project/google_analytics
• flexslider (this is built right into the theme currently)

theme & layout

• port backdropcms theme / build new brorg theme
• create new custom double_fixed layout
• add fancy js layout drawer toggle in borg theme

We're using Github for project management right now, but it has a number of limitations:

• PUSH access required in order to assign labels or organize issues.
• After push access is granted, it allows deletion of entire labels in a way that's dangerous with no undo or confirmation (imagine the entire label for "bug" being deleted from hundreds of issues).
• There's no ability to specify version (we could use labels, but we'll end up with dozens of them).

We need to decide on the best way to solve our long-term project management needs. Should we set up project.module on backdropcms.org? Should we try to bend Github to our needs through API integration? Use another project management tool?

In the Views Slideshow of quotes on the https://backdropcms.org/ front page, there are 2 missing images...

https://backdropcms.org/files/styles/thumbnail/public/photos/earl-miles.jpg
https://backdropcms.org/files/styles/thumbnail/public/photos/develcuy.jpeg

Not sure if the fix is to update the slideshow so the images are optional or find these specific images.

In d.o, one could close an issue even if they were not the owner/original author. How are we to handle this in contrib over at github? Asking because I wanted to close backdrop-contrib/pathauto#1 as a dupe but couldn't.

Hey @sirkitree, really stoked about the work you've done so far on automating our processes.

After managing the queue for a few weeks, it's become clear that we have needs for automated tagging, as well as automated association. Examples:

• When a pull request passes tests, mark it's label as "passing tests"
• Likewise, file a matching label on the associated issue for "passing tests".
• When a pull request fails tests, mark it's label as "failed tests"
• When a pull request fails tests, label the associated issue as "needs work".

Right now there's a bunch of pull requests that are completely unorganized. I loose track of which ones I've already reviewed or not. Worse yet, because pull requests aren't really issues, there's no way to update the associated label on them (and we have the issue tracker disabled). So even manually, there's no way to organize them. By affiliating the issue and the pull request, I think we can make Github label PRs to match their issues, overcoming our permissions problems between the two repositories.

When an issue is marked as closed, all pull-requests associated with that issue should also be closed automatically.

We should create an API website matching api.drupal.org, leveraging the API module to index our fork of the code.

Unlike Drupal's API website, I'd like to see the API website be the conical location for all API documentation, including:

• Doctrine-based documentation (api.module).
• The topic-based documentation (https://drupal.org/developing/api)
• API change log (https://drupal.org/list-changes?to_branch=8.x)

So rather than being a read-only site, the API website actually is actually where documentation for Backdrop is created and stored.

I've already made an issue specifically for changelogs here: #14

Is this acceptable/recommended:

function simplify_config_info() {
  $prefixes['simplify.global'] = array(
    'label' => t('Global fields'),
    'group' => t('Simplify'),
  );
  $prefixes['simplify.nodes'] = array(
    'label' => t('Node fields'),
    'group' => t('Simplify'),
  );

  return $prefixes;
}

Or should this be placed at the top of that function:
$prefixes = array();?

This page should be updated once we work out what the standard should be: https://backdropcms.org/develop/php-standards#arrays

It would be nice to have a basic SCSS coding standards page in the handbook. Such a page should probably not be specific to SASS or LESS.

This is assuming that BackdropCMS will officially adopt SCSS in core or allow it in contributed modules.

Started a conversation concerning adding change records over at backdrop-issues and have noticed a few things which should probably be updated.

• Code isnt apparently being updated on the API site automatically - no reference found to layout or admin bar modules.
• References to Drupal 7 still remain in the "API Navigation" block (but only when browsing change records)
• The first item in "API Navigation" block is a link to "Backdrop Initial Release" but this in turn only links to a short blurb about views. Not sure what it should actually link to.
• Change records are listed as a big unformatted list (labelled "All") without dates, categories. Its a short list so far but will be a pain to scan through when it grows, especially if one cannot discern chronological order of changes.
• There is no way to search or filter change records (see previous)
• Github Issues - Links are not formatted as links but plain text.
• Code blocks (wrapped in "code" tags) do not wrap at line endings causing unreadable blobs of code for functions and lists etc. Some css white-space markup missing somewhere?

Thats it so far.

Implement Munin to monitor sites, servers and other infrastructure.

"Switch easily from Drupal 7" section:

...With an familiar architecture

should be "With a familiar architecture"

Thought I'd make a suggestion regarding the weekly meeting videos: make a video specifically for introducing new users to Backdrop (basically what Jen says during the first few minutes of each weekly meeting video) and point new users to this rather than giving the same intro spiel each week. This'll make it nicer for regular viewers (like myself) who currently hear the same first few minutes each time, and will also provide a video you can post to BackdropCMS.org.

This is related to #19

I'm not familiar with how the instances of backdropcms.org are configured, but unless there is a reason for http://live.backdropcms.org/ to exist independently for http://backdropcms.org/, the domains should be redirected to a single domain... or there should be an .htaccess password prompt or something like that preventing bots from crawling the alternative URLs.

Failing to do that will likely get backdropcms getting burried by almighty Google. It's much easier to avoid that hole than dig out of it.

Right now our repositories are split into code and issues due to limitations of the Github permissions system (see #2). This means that when we reference an issue in a commit, i.e.:

Issue #10: Fixes some issue with some module.

This commit does not automatically post a comment in issue 10 like it would if the issue tracker and code repository were the same thing. We should be able to leverage the Github API to restore this automatic functionality between repositories.

Note that Github already allows cross-repository linking (per https://help.github.com/articles/issues-only-access-permissions), but the syntax is awkward. We'd prefer that linking was simply automatic based on the names of the repositories. i.e. a pull request on the "backdropcms.org" repository would automatically associate commits in the "backdropcms.org-issues" repository issue tracker.

I think it might be beneficial to add the latest Drupalize.Me podcast to the homepage for people looking for more information about Backdrop.

Thoughts?

http://www.lullabot.com/blog/podcasts/backdrop-drupal-fork

On http://backdropcms.org/about/contribute, the link to "You write code? Great! See our handbook on contributing code" links to http://live.backdropcms.org/develop/code. Not sure if absolute links like that ended up anywhere else, but might be worth checking.

Hi everybody,

after installing Backdrop CMS as multisite installation I am getting this error:

Exception: The configuration directory in settings.php is specified as 'files/config_6e725e8138933c0593de000d7d5bb4e7/active', but this directory is either empty or missing crucial files. Check that the $config_directories variable is correct in settings.php. in _backdrop_bootstrap_configuration() (line 2668 of /data/web/backdrop/core/includes/bootstrap.inc).

while trying to access the homepage. After some digging I have found out that although my config files are successfully created in sites/studiozavodou.sk/files, Backdrop is trying to get them from files/ directory in installation root. I have proved this by copying my config files to this directory and this error disappeared.

I have tried to changed the config directory path in settings.php so I added the sites/studiozavodou.sk part at the begining of it, however, this caused another error, because it seems to that when Backdrop is trying to update config files, it uses correct base directory (sites/studiozavodou.sk), so this part got duplicated and Backdrop threw another exception, trying to update file in sites/studiozavodou.sk/sites/studiozavodou.sk/files....

Long story short (conclusion):

On multisite installation, Backdrop does not take the multisite base path into account while reading config files, but it does while trying to update them.

Blocks in drupal are crap, there are better options like box or bean.

I prefer beans because you can build different kind of blocks, not only the "title-text", you can create an slidshow with a bean that has a title and an image field.

Also the block configuration is crap, you can not "use the same block in different places", context is the best options but it's not easy to configure, something similar to the way of work of path_breadcrumbs, or paths_metatags will be great.

On the PHP Coding Standards page, the anchor link for Arrays doesn't work (it's missing an 's').

• New docs are ending up in change records for some reason. See the last few "change records".
• Plus I did a book page on converting modules and it isn't showing up under the parent book (should be under creating modules) in the sidebar menu.
• Code wrapped in <?php tags are displaying HTML instead of links. See "Let Backdrop know about your module's config" on https://api.backdropcms.org/node/28621.

Needs fixing.
Also reminder:
backdrop-ops/docs.backdropcms.org#8
backdrop-ops/docs.backdropcms.org#7

We need to build an update server for the core Update module to use. It's just a PHP script that returns current versions, and stable releases of core and contrib.

See the associated issue for Update.module in core itself at backdrop/backdrop-issues#396.

We'll need to let the authors of pull requests know when newer (probably more relevant) PRs have been created.

As well as updating the original issue, it would be nice if we could add a comment to previous PRs notifying them that they are now out of date.

"@whoever has created a new pull request for this issue: link"

Similar to #11

Split off from #29

Not sure if this is where this should go, but thought I should mention this after hunting help on a Drupal module recenlty. BD should require help of some kind. Drupal has a variety of methods of informing the end user but it is inconsistent and not required. So you might run into a readme.txt file, install.txt file, documentation on site, documentation on a custom site, Drupal help, Advanced. Help, or if youre unlucky, nothing at all and get to Googling.
We should require one of the above for contrib modules.

Hi @mikemccaffrey! Per your request, here are the 5 top topics for BackdropCMS.org in a not-quite 1-5 explanation, most important (1) to least (5):

1. Describing Backdrop. What it is, how it relates to Drupal. Why it exists.
2. Getting involved with Backdrop. Organizational structure, code repositories.
3. Feature list of Backdrop. Selling Backdrop to new users. Over time, I expect this to move to the number 1 spot, but for our early audience, this is number 3.
4. Support - Documentation (non-existent/minimal at this point) and StackExchange tag.
5. Download. Modules and Themes. Again, non-existent at this point so minimal importance now but increasing over time.

What I imagine the homepage to look like is a large explanation homepage. By the time they get to the bottom of the homepage, they'll have a full understanding of why Backdrop exists, and hit a least points 1 and 2 above.

Some example homepages that have the "big sell" type homepages:
https://vimeo.com/
http://2012.buildconf.com/
https://www.acquia.com/
http://2013.badcamp.net/about

I'm working on writing up the main homepage sell. For the first iteration I thin the homepage is pretty much all we'll include until we can do things like build out the issue tracker, blog, documentation, etc. areas.

For support, I'd like to separate support requests entirely from bug tracking and development (which ultimately will live on backdropcms.org, even though we're using Github right now). Google Docs does a great job of specifically referencing an external "questions" forum on StackExchange: https://developers.google.com/google-apps/documents-list/support

I think we should do the same thing, separating the expectation between "this is a bug to be tracked" and "I have a question about the software".

I'll work on the homepage content, but I hope that's enough to give you something to mull over!

The border radius on the buttons should be bumped up to 30px so the edges are perfectly rounded.