Naming is at once the setting of a boundary, and also the repeated inculcation of a norm.
A couple weeks ago, I posted about a problem I was having getting RSS to validate because the description element contained HTML markup.
The solution turned out to be as easy as I expected, once I found the right place to look. The first place I went was the Views module, where I found views-view-row-rss.html.twig in the templates directory. "Perfect", I thought, "that's my boy." A quick edit later, followed by a couple cache clears and some head-scratching, I still wasn't seeing my change.Barrett Sat, 08/15/2015 - 10:19
It's been a busy month in Drupal documentation land. Here's an update from the Documentation Working Group (DocWG) on what has been happening in Drupal Documentation in the last month or so. Sorry... because this is posted in the Core group as well as Documentation, comments are disabled.
If you have comments or suggestions, please see the DocWG home page for how to contact us. Thanks!Notable Documentation Updates
(pages or sections that have been worked on recently, see notes below)
See the DocWG home page for how to contact us, if you'd like to be listed here in our next post!Thanks for contributing!
(list of how many people have made updates in the last month, and the top few contributors, see notes below)
Since July 15th (our previous TMIDD post), 234 contributors have made 705 total Drupal.org documentation page revisions, including 4 people that made more than 30 edits -- thanks everyone!
Extra big shout-out to these contributors.
- lolandese (111 revisions)
- Wim Leers (49 revisions)
- jhodgdon (41 revisions)
- Francewhoa (30 revisions)
In the core issue queue there's been a lot of movement to improve in-line documentation as we continue to get closer to a release of Drupal 8. This patch to improved the TypedData documentation is a great example of the kind of work that's being done. https://www.drupal.org/node/2548279
In addition, there were many many commits to Drupal Core and contributed projects that improved documentation -- these are hard to count, because many commits combine code and documentation -- but they are greatly appreciated too!Documentation Priorities
The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.
Work on the Drpual 8 User Guide is moving along splendidly. We had two IRC meetings in the last month and the level of involvement has been great. Helping with this documentation is a great way to get started with documentation and to learn a bit about Drupal 8 while you're at it. The focus right now is on writing a first draft of each of the topics in the guide, and work is also underway to figure out a final home for the new guide in https://www.drupal.org/node/2522024. Follow https://groups.drupal.org/documentation for announcements and join us for our next IRC meeting.
If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?
The Drupal Association staff have recently updated their 2015 roadmap and it currently includes a couple of big wins for documentation. Including work to convert sections of the community documentation into a more maintainable format. The issue here https://www.drupal.org/node/2533684 doesn't have a lot of information soon, but keep on eye on it. And/or watch this recording of the presentation from DrupalCon LA about the work being done on content strategy for Drupal.org to get an idea of what's coming. https://events.drupal.org/losangeles2015/sessions/content-strategy-drupa...Upcoming Events
- DrupalCon Barcelona, Spain, 21-25 September, with a session Let's talk about documentation and a documentation sprint on Drupal 8 documentation and the D8 User Guide. Please sign up for the sprint! Members of the DocsWG will be in attendence at DrupalCon and would love to chat with you about your ideas for improving Drupal's documentation or to help you find ways to get involved so come say hello anytime during the week.
If you're attending or helping to organize a Drupal event that will feature a documentation related sprint, or sessions let us know and we'll get it added to the list.Report from the Working Group
We just recently had our regular monthly meeting, though it had actually been over a month since the last time we met. We didn't have a whole lot to discuss in that period, and had been putting a lot of time and effort into getting the Drupal 8 User Guide project underway. At our last meeting the big thing that came up was the need to develop a clear set of guidelines for when it is appropriate to delete a comment from either the community documentation or the api.drupal.org documentation. https://www.drupal.org/node/2515002. We've jotted down some ideas and plan to discuss this further at our next meeting in September. Afer which we'll post the ideas we've come up with for consideration before making anything official. Let us know in the issue if you've got any thoughts about what this should look like.
I recently had time to install and take a look at Drupal 8. I am going to share my first take on Drupal 8 and some of the hang-ups that I came across. I read a few other blog posts that mentioned not to rely too heavily on one source for D8 documentation with the rapid changing pace of D8 the information has become outdated rather quickly.
World of Tanks maker Wargaming.net is seeking an a graphics engineer to take a lead role in working on the company's current and upcoming projects alongside the team in its Chicago, Illinois studio. ...
Hear the four pillars that guided the world design for Bungie's remarkably popular Destiny, from art director Christopher Barrett and design director Joe Staten in this free GDC 2013 video. ...
Real talk: Your amazing, innovative, one-of-a-kind game/story/character/song has almost certainly been done before. Probably more than once. At GDC 2014, Nika Harper explains why that shouldn't stop you. ...
If the stress of pressing the wrong button on a live website is familiar to you, you need the Environment Indicator module! On large Drupal projects you will ...
The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, August 19.
This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).
There will be no bug fix/feature release on this date; the next window for a Drupal core bug fix/feature release is Wednesday, September 2.
Many times you want to execute an operation over a list of entities. Sometimes you will want to retroactively apply a default value to a certain field, other times you will want to export the articles tagged as Drupal to a CSV file, etc.
This drush command simplifies that process for you. You only need to write the callback function that does your operation, given an entity. All valid callbacks will receive the entity type as the first argument and the loaded entity as the second parameter.
Provides Drupal Commerce with direct KBC Paypage integration.Sponsored by:
This module for Drupal Commerce extends Commerce Addressbook module and allows to add customer profiles from Register form. Also it allows to setup what field should be used to show the values for ADDRESSES ON FILE select-list on Checkout page.
We met again today to discuss critical issues blocking Drupal 8's release (candidate). (See all prior recordings). Here is the recording of the meeting video and chat from today in the hope that it helps more than just those who were on the meeting:
If you also have significant time to work on critical issues in Drupal 8 and we did not include you, let me know as soon as possible.
The meeting log is as follows (all times are CEST real time at the meeting):
[11:07am] alexpott: https://www.drupal.org/node/2501931
[11:07am] Druplicon: https://www.drupal.org/node/2501931 => Remove SafeMarkup::set in twig_render_template() and ThemeManager and FieldPluginBase:advancedRender [#2501931] => 117 comments, 34 IRC mentions
[11:08am] alexpott: https://www.drupal.org/node/2549943
[11:08am] Druplicon: https://www.drupal.org/node/2549943 => [plan] Remove as much of the SafeMarkup class's methods as possible [#2549943] => 16 comments, 6 IRC mentions
[11:14am] plach: https://www.drupal.org/node/2542748
[11:14am] Druplicon: https://www.drupal.org/node/2542748 => EntityDefinitionUpdateManager::applyUpdates() can fail when there's existing content, leaving the site's schema in an unpredictable state, so should not be called during update.php [#2542748] => 100 comments, 24 IRC mentions
[11:56am] catch: https://www.drupal.org/node/2551341
[11:56am] Druplicon: https://www.drupal.org/node/2551341 => Update test database dump should be based on beta 12 and contain content [#2551341] => 0 comments, 1 IRC mention
[11:58am] jibran: https://www.drupal.org/node/2464427
[11:58am] Druplicon: https://www.drupal.org/node/2464427 => Replace CacheablePluginInterface with CacheableDependencyInterface [#2464427] => 157 comments, 22 IRC mentions
[12:01pm] jibran: plach: is it bells time on the call? :P
[12:02pm] plach: jibran: yeah :)
[12:08pm] jibran: https://www.drupal.org/node/2349819
[12:08pm] Druplicon: https://www.drupal.org/node/2349819 => String field type doesn't consider empty string as empty value [#2349819] => 89 comments, 8 IRC mentions
If you can not install MOD_PAGESPEED or other HTML compressor on webserver level, this module can help you reach a higher score on the speedtest, and eventually a higher pagerank.
The idea is that instead of looping through all the renderable regions to compress the HTML output, I duplicated the drupal_deliver_html_page method and minify the entire HTML output at once.
One of the core tools used in many software development circles is Git - a 'version control system' which enables individuals and groups to have a complete record of all the code changes throguhout the life-cycle of a project. As you can imagine, starting to use version control to save progess, rather than just the usual ctrl + S takes a bit of getting used to!
As a new developer, learning all of this stuff is pretty intimidating along with all of the other new knowledge. So I wrote the following guide, which is the document I would've like to have been given when I started.Introduction
Have no fear, Git is here to help. Nothing is lost, once commited to a repository. And there are many ways to organise your work, although this flexibility does mean it can be more complicated to store/locate your work. Commits are the core concept though, so get used to them.
It is useful to append the idea of 'always commit your work' to the paradigm 'always save your work'.
Git stores different "versions of reality" and you can switch between them like a multiverse! If you want to branch off and do something weird and crazy this is perfectly fine - everything in the other universes (branches) is unharmed.
Here are a couple of good tutorial links to get you started:
- Practice and visualise manipulating an example Git repository
- Hands on, step-by-step, bite-sized explanation of the core git concepts
A commit is a change to a set of files. It can consist of new files, altered files, deleted files and directories etc. In the real world a commit represents a logical/intuitive point to package some work you've done. After a certain piece of functionality has been completed, or everything required for a ticket has been done, or just at the end of the day (althought this isn't considered good practice by all as it results in incomplete work in the repository). Every commit is given it's own message, so you have the opportunity to show why this is a logical or intuitive place to be committing.
There can be a very large number of commits in a repository, which are connected in a variety of ways. One thing that is important to get your head around is that you can shift the whole filesystem to be the way it was at any commit. This is referred to as a "checkout" of a certain place in the structure (although the command is used slightly differently elsewhere). The process of checking out moves the "HEAD" to a different place in the repository and therefore looks at a version of the files from a different point in history.Staging Areas
The mechanism for creating commits is by placing the required changes, piece by piece if required, into the staging area. Git is aware of things that are in the 'work tree' (the filesystem you are looking at), that are different to the repository. It allows you to chose from these things by executing a command like these:
Put one file into the staging area:~$ git add path/to/altered.file
Stage any changes within this directory:~$ git add path/to/directory
This stages AND performs the next step - committing - all in one:~$ git commit -am "useful message"
This is quicker but less flexible. Be sure to know which files are going into the commit. Also, this only adds files that are already in the repo. If you need to add a new file for the first time, you have to use 'git add' first.
After adding some files, you can do 'git status' to display everything staged for a commit in green. If you are happy with what is prepared (you can use 'git diff' to see the details of what has changed) you can go ahead and run:~$ git commit -m "useful message"
That commit is now locked down in the repository. You will always be able to go back to it, event after future commits.Branches
Branching in Git is the action of deviating a sequence of commits from any pre-existing sequence. This is like taking your code to another dimension - where it can't mess up anything in another one. The ability to branch gives lots of flexibility for different workflows and gives Git its characteristic look in diagrams.
A typical workflow may consist of using a branch for working on a particular ticket or developing a piece of functionality. This "feature branch" will most likely deviate from a main development branch. Once created this branch will contain any number of commits working towards a finalised unit of work. After the work is ready, this branch can be merged back into the dev branch and this becomes the new start point for future feature branches.Branchy Commands
Create a branch (relative to the current branch):~$ git branch name-of-branch
This Branch will deviate from wherever HEAD is in the repo. Though the new branch will not be checked out at this stage.
List all available branches:~$ git branch
Lists available branches.
Creates a new branch and checks it out in a oner:~$ git checkout -b name-of-branch Repositories
Most workflows will consist of interactions with different repositories. Typically you will use a hosted central repository (BitBucket, GitHub etc.) which multiple collaborators can send their work to. It is in the central repository that the main workflow (feature branching and managing merges) occurs.
It is good practice to keep your local repo as similar in structure to the central remote one, although this does not necessarily need to happen. In principle you can perform the command below between any arbitrary repos, and Git will do its best to handle any differences it encounters. For example, two repos may not have the same branch structure, i.e. branches with the same content may have different parent commits. This is not necessarily a problem, depending on the nature of the code changes, but it may explain issue with merges later on down the line.Commands and concepts for moving changes between repositories.
fetch - Gets commits from a remote repository so they exists on a branch parallel to the local counterparts. So for example 'git fetch dev' gets a local version of the branch that is called "dev" in the remote repo (which is usually referred to as "origin"), but locally is called "origin/dev". This sounds confusing, but the idea of the "parallel" branches on fetching is illustrated in this interactive tool - just type "git fetch" in the command box!
pull - Does the above except it would also attempt to bring the local version of the "dev" branch up to date with any new stuff by performing a merge. The merge happens locally. The 'git pull' command acts on the current branch and is quite automatic. Here's a good summary of the differences between fetch and pull.
push - Attempts to send changes from local to remote. You may need to pull first to have the necessary information about the structure of the remote repo. Push requires Git to know what branch it's pushing to. You can specify that each time by executing 'git push origin branch-name', or you can set an "upstream branch" using 'git push -u origin branch-name' which lets Git know that it should always push between this pair of branches. Thereafter you can just do 'git push' and it knows where to go.Stashing
Sometimes you are asked to "stash" when switching branches. Stashing takes uncommited changes and puts them somewhere safe for you to re-apply later.
If you are asked to do this, simply do a 'git stash' - to put the changes in the stash. Then go to the new branch with 'git checkout new-branch-name'. Finally 'git stash apply' puts those uncommited files onto the new branch.
The stash never goes away. You can always access older stashed items even if new ones have been created.
Why does this happen? For unstaged changes to files, Git thinks about the last commit that involved a change to that file - a "parent commit" (this may be the initial commit). If you do a switch that makes it unclear which parent commit to use for a file, a stash becomes necessary.Merging (and conflicts)
Merging happens in various guises at various points in the workflow. Generally speaking, it involves making two branches into one so that the information in both is maximally represented. Most of the time the information can be matched up well, but sometimes it will be ambiguous as to which branch's change should be used. I.e. in some files there may be a different change to the same line(s) of code. When this happens Git will present the two options to you by writing them both into the file, using a certain convention to show which branch each is from. This is called a merge conflict. Fixing consists of simply editing the files and deleting the bits you don't need.
The basic command for merging is:~$ git merge target-branch-name
This will bring any differences from the target branch into HEAD (current branch). If this is successful (usually) a new commit will be created which has two parent commits, although you can also create a fast-forward merge in some cases.
Hopefully these notes and basic principles will help you get to grips with Git!Ashley George