سیاره دروپال

Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to خوراک سیاره دروپال
Recently I set out to make a simple instrument for running simpletest tests without having LAMP stack installed on your local environment. I needed this for two reasons:
  1. for running tests locally
  2. for running tests on CI server
I've decided to use Docker and create monolith container with Drupal and all the LAMP stuff inside and here what I've got: docker-tester.
Read more »

Since the release of Drupal 8 with a standardized way of managing translations, many sites running Drupal 7 are making a switch to Drupal 8. In Drupal 7 there are two ways to translate content:

  1. Using the content_translation module. The D7 core way of translating content, where every translation is a separate node.
  2. Using the entity_translation module. Maintains one node with a unique nid, while translations take place at the field level.

In this article we will discuss how to migrate content translations created with the content_translation module from Drupal 7 to Drupal 8. You can find our tutorial about migrating translations that use Entity Translation here.

This article would not have been possible without the help of my colleague Dave. ¡Gracias Dave!

The problem

We have a Drupal 7 database containing article nodes, which might have translations in English, Spanish and French. Some of these nodes are language-neutral, i.e. non-translatable. Our target is to migrate the Drupal 7 nodes into a Drupal 8 website, preserving the translations.

Before we start
  • Since this is an advanced migration topic, it is assumed you already know the basics of migration. If are new to migrations in Drupal 8, I recommend that you read about migrating basic data to Drupal 8 first.
  • If you'd like to run the migrations in this example yourself, see the quick-start documentation in our drupal migration i18n example repository.
  • The source website used in this example is Drupal 7.54.
  • The destination website used in this example is Drupal 8.3.x. However, an alternative solution for earlier versions is included towards the end of the article.
The module

To write the migrations, we create a module - in our case, migrate_example_i18n. There's nothing special about the module declaration, except for the dependencies:

  • migrate_plus and migrate_tools provide various features for defining and executing migrations.
  • migrate_source_csv: Will be used for demonstrating migration of translated content from non-Drupal sources in an upcoming article.
  • migrate_drupal: This module provides tools for migrating data from older versions of Drupal. It comes with Drupal 8.x core. Since this migration uses a Drupal 7 site as a source for its data, we need the migrate_drupal module.
How do translations work?

    Before jumping into writing these migrations, it is important to mention that Drupal 7 and Drupal 8 translations work very differently. Here's the difference in a nutshell:

    • Drupal 7: When we translate a node, a new node is created with a different ID. This translated node has a property named tnid, which stores the ID of the original node, linking the two nodes together. For language-neutral or untranslated content, the tnid is set to 0.
    • Drupal 8: When we translate a node, no new node is created! The translation is saved in the fields of the original node, but with a different language code.

    So just like we do when migrating translated content from Drupal 6 to Drupal 8, we create two migrations:

    • The example_dog_base migration will migrate the original content of each node, untranslated.
    • The example_dog_i18n migration will migrate only translations and associate them with original content created by example_dog_base.

    We group the two migrations using the example_dog migration group to keep things clean and organized. Then we can execute both migrations with drush migrate-import --group=example_dog --update.

    Step 1: Base migration

    We start with example_dog_base to migrate all base data or non-translations. Described below are some noteworthy parameters:

    Source source: plugin: d7_node node_type: article key: drupal_7_content constants: uid_root: 1 node_article: 'article'
    • plugin: Since we want to import data from a Drupal installation, we need to set the source plugin to d7_node. The d7_node source plugin is introduced by the migrate_drupal, module and it helps us read nodes from a Drupal 7 database without having to write queries manually. Since Drupal 8.3.x, this plugin supports translations created with the content_translation module. If you are using an older version of Drupal 8, then check the alternative solution provided towards the end of this article.
    • node_type: This tells the source plugin that we are interested in just one particular Drupal 7 node type, namely article.
    • key: Our Drupal 7 data doesn't come from our main Drupal 8 database - instead it comes from a secondary database connection. We choose a key to identify each such connection and we need to tell the source which such key to use. The keys themselves are defined in the $databases variable in our settings.php or settings.local.php. See the example settings.local.php file to see how it's done.
    • constants: We define some hard-coded values under this parameter.
    • translations: Notice there is no translations parameter here. The default value (false) tells the source plugin that we're only interested in migrating non-translations, i.e. content in the base language and language-neutral content.
    Destination destination: plugin: 'entity:node'
    • plugin: Since we want to create node entities in Drupal 8, we specify this as entity:node. That's it.
    • translations: Again we do not define the translations parameter while migrating base data. Omitting the parameter tells the destination plugin that we are interested in creating fresh nodes for each record, not translations of existing nodes.
    Process type: constants/node_article langcode: plugin: default_value source: language default_value: und uid: constants/uid_root title: title body: body field_one_liner: field_one_liner sticky: sticky status: status promote: promote

    This is where we map the old node properties to the new node properties. Most of the properties have been assigned as is, without alteration, however, some noteworthy properties have been discussed below:

    • nidThere is no nid parameter here, because we don't care what nid each new node has in Drupal 8. Drupal can just assign a new nid to each node in the normal way.
    • type: We specify that we want to create article nodes.
    • langcode: The langcode parameter was formerly language in Drupal 7, so we rename it here. Also, if a Drupal 7 node is language-neutral, the language property will have no value. In that case,  we default to und.

    This takes care of the base data. If we run this migration with drush migrate-import example_hybrid_base --update, all Drupal 7 nodes which are in base language or are language-neutral will be migrated into Drupal 8.

    Step 2: Translation migration

    We are halfway through now! All that's missing is migrating translations of the nodes we migrated above. To do this, we create another migration with the ID example_dog_i18n:

    source: plugin: d7_node node_type: article translations: true # ... destination: plugin: 'entity:node' translations: true process: nid: plugin: migration source: tnid migration: example_dog_base langcode: language # ... migration_dependencies: required: - example_dog_base
    • source:
      • translations: We set this to true to make the source plugin read only translations.
    • destination:
      • translations: We set this to true to make the destination plugin create translations for existing nodes instead of creating fresh new nodes.
    • process:
      • nid: In this case, we do care what the Drupal 8 nid is for each node. It has to match the nid for the untranslated version of this content, so that Drupal can add a translation to the correct node. This section uses the migration (migration_lookup) process plugin to figure out the right nid. It tells Drupal to check the previously-executed example_hybrid_base migration for a D6 node that has the same tnid as this D6 node. It will then then reuse the resulting nid here.
      • langcode: We define the language in which the translation should be created.
    • migration_dependencies: Since we cannot add translations to nodes that do not yet exist, we tell Drupal that this migration depends on the base migration example_dog_base. That way, the base migration will run before this migration.

    That's it! We can run our translation migration with drush migrate-import example_dog_i18n --update and the translations will be imported into Drupal 8. Alternatively, we can use the migration group we defined to run both these migrations at once - the base migration will automatically be executed first and then the i18n migration. Here's how the output should look:

    $ drush migrate-import --group=example_dog --update Processed 7 items (7 created, 0 updated, 0 failed, 0 ignored) - done with 'example_dog_base' Processed 7 items (7 created, 0 updated, 0 failed, 0 ignored) - done with 'example_dog_i18n'

    You can check if everything went alright by clicking the Translate option for any translated node in Drupal 8. If everything went correctly, you should see that the node exists in the original language and has one or more translations.

    Article migrated from Drupal 7 to Drupal 8

    Alternate Solution for Drupal 8.2.x and Older

    The example code for this article works out of the box with Drupal 8.3 or higher. However, it will not work with earlier versions of Drupal 8. For Drupal 8.2 or older, we need to use a custom source plugin (inspired by the d6_node plugin). All we have to do is use the D7NodeContnentTranslation source plugin included in the code for this example, like source: d7_node_content_translation. This custom source plugin adds support for the translations parameter, which in turn makes the migration of content translations work correctly.

    Next Steps + more awesome articles by Evolving Web

    Since the release of Drupal 8 with a standardized way of managing translations, many sites running Drupal 7 are making a switch to Drupal 8. In Drupal 7 there are two ways to translate content:

    1. Using the content_translation module. The D7 core way of translating content, where every translation is a separate node.
    2. Using the entity_translation module. Maintains one node with a unique nid, while translations take place at the field level.

    In this article we will discuss how to migrate content translations created with the entity_translation module from Drupal 7 to Drupal 8. You can find our tutorial about migrating translations that use Content Translation here.

    This article would not have been possible without the help of my colleague Dave. Merci Dave!

    The problem

    We have a Drupal 7 database containing article nodes, which might have translations in English, Spanish and French. Some of these nodes are language-neutral, i.e. non-translatable. Our target is to migrate the D7 nodes into a D8 website, preserving the translations.

    Before we start
    • Since this is an advanced migration topic, it is assumed you already know the basics of migration. If you are new to migrations in Drupal 8, I recommend that you read about migrating basic data to Drupal 8 first.
    • This article assumes that you have read our previous article on how to migrate content translations from Drupal 7 to Drupal 8 or have the relevant knowledge.
    • To execute the migrations in this example, you can download the drupal migration i18n example repository from GitHub. The module should work without any trouble for a standard Drupal 8 install. See quick-start for more information.
    • To see the example migrations in action, you need:
      • A Drupal 8 site.
      • The relevant D7 database, since we are migrating data from a Drupal 6 site.
      • Drush will be required to execute migration commands.
    The module

    To write the migrations, we create a module - in our case, it has been named migrate_example_i18n. Just like migrating content translations from D7 to D8, we create 2 YML files to define:

    • The example_creature_base migration will migrate all base data or non-translations.
      • The source/translations parameter is omitted or set to false.
      • The destination/translations parameter is omitted or set to false.
    • The example_creature_i18n migration will migrate all translations.
      • The process/nid is configured to use the migration plugin to lookup the node in the base language.
      • The source/translations parameter is set to true.
      • The destination/translations parameter is to true.
      • The migration_dependencies parameter declares example_creature_base as a dependency.

    We group the two migrations using the example_creature migration group to keep things clean and organized. Then we can execute both migrations with drush migrate-import --group=example_creature --update.

    How to migrate Entity Translations?

    Entity translations! Drupal 7 content translations are supported since Drupal 8.3. At the point of writing this, there is no standard method for migrating entity translations to Drupal 8. In this example, we will migrate D7 nodes translated with the entity_translation module, however, the procedure should be similar for other entity types as well. Before we start, here are some notes about what's so different about entity translations:

    • All translations have the same entity_id. So, for a translated node, the entity_translation module will result in only one entry in the node table.
    • Translation information, certain metadata and revision information for entities is stored in the entity_translation table.

    So if an English node with ID 19 has translations in Spanish and French, the entity_translations table has the following records:

    An extract from the entity_translation table. entity_type entity_id revision_id language source uid status translate created changed node 19 1 en   1 1 0 1485800973 1487198982 node 19 1 es en 1 1 0 1485802336 1487199003 node 19 1 fr en 1 1 0 1487185898 1487198969

    The above data structure is significantly different from the content translation structure. In fact, Drupal 8 handles translations much like the entity translation module! Hence, to handle entity-translations, we must take the entity_translation table into consideration, which the core d7_node source plugin does not do at the time of writing this article. Hence, we override the d7_node source with a custom source plugin named d7_node_entity_translation.

    class D7NodeEntityTranslation

    This is where we jump into code! We override certain methods of d7_node source to add support for the entity_translation table.

    class D7NodeEntityTranslation extends D7Node { // Determines if the node-type being translated supports entity_translation. protected function isEntityTranslatable() {} // Depending on the "source/translations" parameter, this method alters // the migration query to return only translations or non-translations. protected function handleTranslations(SelectInterface $query) {} // This method has been overridden to ensure that every node's fields are // are loaded in the correct language. public function prepareRow(Row $row) {} // This method is called by the prepareRow() method to load field values // for source nodes. We override this method to add support for $language. protected function getFieldValues($entity_type, $field, $entity_id, $revision_id = NULL, $language = NULL) {} // Since all source nodes have the same "nid", we need to use a // combination of "nid:language" to distinguish each source translation. public function getIds() {} }

    Here's a quick look at the changes we need to make:

    • function getIds() tells the migrate API to use one or more source properties which should be used to uniquely identify source records. When working with entity translations, all translations have the same entity_id, but they have a different language. We override this method to tell Drupal to consider both the entity_id and the language properties to uniquely identify source records. So, the source records are uniquely identified something like 19:en, 19:es, 19:fr instead of using just 19.
    • function handleTranslations() is the method which adds support for the translations parameter we use in the source plugin. The translations parameter tells Drupal whether to migrate entities in their base language or to migrate translations. We override this method to:
      • See if the node type being migrated supports entity translations.
      • If the node type supports entity translations, then we INNER JOIN entity_translation and read translation data and some entity metadata, like date of creation, date of updation, etc from that table.
    • function prepareRow() as the name suggests, prepares a row of source data before it is passed to the process plugins. At this stage, field data is also attached to the source data. However, it does not load field data in the language specified in the source row. To overcome this problem, we override the getFieldValues() method and make sure it loads the field data in the same language as specified in the source row.

    That's it! You should now be able to run the migration with drush migrate-import --group=example_creature --update. The output should look something like this:

    $ drush mi --group=example_creature --update Processed 9 items (9 created, 0 updated, 0 failed, 0 ignored) - done with 'example_creature_base' Processed 9 items (9 created, 0 updated, 0 failed, 0 ignored) - done with 'example_creature_i18n'

    Note: Keep an eye out for Drupal core updates. If the drupal_migrate module adds support for entity translations, migrating entity translations might become much easier.

    Next Steps + more awesome articles by Evolving Web
    Start:  2017-06-15 (All day) - 2017-06-18 (All day) America/Toronto Event type:  Sprint

    Several key contributors to the Migrate Initiative will be at the sprint at DrupalCamp Montreal on Sunday (and to some degree on earlier days as well). Join contributors Adam G-H (phenaproxima), Maxime Turcotte (maxocub) and Dave Vasilevsky (vasi) in person. Initiative coordinator Mike Ryan (mikeryan) is also planning to join remotely on Sunday.

    Among the most important Migrate critical issues on the table that are planned to be worked on is auditing for potential ID conflicts before upgrading from older versions. This is the most thorny outstanding issue for the initiative. Use cases and feedback in general is welcome. Further migrate issues are categorized and tracked in the Migrate triage spreadsheet (update regularly). These include handling import of private files, adding back support for incremental migrations, redirecting for obsolete content translations when they are merged in the migration, etc. All of those need helping hands and this is a great time to get experienced with help from the most well versed people in the field.

    If you cannot join the sprint this time, your involvement is more than welcome anytime. The migrate team has weekly meetings on every Thursday at alternating meeting times. See https://www.drupal.org/node/2735059#meet for the upcoming meetings.

    Two of the biggest retailers in the world are getting together. This morning, Amazon.com, the juggernaut that continues to put massive pressure on brick-and-mortar retailers, announced that it is buying Whole Foods, the popular, high-end organic foods grocer.

    Both companies are major stakeholders in the Drupal ecosystem: Amazon made an investment in Acquia in 2014, and much of Acquia’s hosting infrastructure relies on Amazon Web Services. Whole Foods, for its part, has used Drupal for its web presence for at least five years—if not much longer—and holds Acquia as a key partner. Acquia Drupal is a significant part of the Whole Foods DevOps story. (I can just imagine that email from the Whole Foods Accounts Payables department to Acquia: “Send the bill to Amazon.”)

    From a presentation at an Acquia event:

    So why would Amazon jump out and make this purchase? The answer is complex and multi-faceted.

    For Amazon, it's all about the data.

    First, Amazon is, at its core, a data company. They use shopping history and patterns to sell us things we need before we even know that we need them. With all the newly acquired data from Whole Foods upper-end clientele, Amazon can make more efficient stock decisions in both the retail and physical stores. In February, Whole Foods Chief Executive John Mackey said that they would retain the services of Dunnhumby, a customer data and insights company, to inform merchandising and services (in other words, help us stock our shelves and get our prices down). I can’t help but think that Amazon could do even better.

    Distribution

    Second, this acquisition gives Amazon access to a grocery distribution network that enhances their own. It creates more markets for home grocery delivery. Nomura Instinet analyst Anthony DiClemente recently said that the grocery industry remains one of the largest and most under-penetrated markets for Amazon. Well, that just changed.

    How convenient could Whole Foods home delivery be? As Dries has demonstrated in recent keynotes (blog post: http://buytaert.net/cross-channel-user-experiences-with-drupal), I can envision a future where I ask my Echo Dot for some free-range chickpeas and organic shampoo and a Whole Foods van shows up at my door an hour or two later with my products (and as of today, with a sizable charge on my debit card).

    The Whole Foods brand - a trip down memory lane

    Third, it gives Amazon a very strong brand that is associated with organic groceries and high-end shopping experience.

    I’m from Austin, and I’ve been shopping at Whole Foods since there was a single store in the early 80s. My family lived in nearby Temple so once a month we’d drive to Austin so Mom could shop at Whole Foods while us kids ran around the nearby Book Stop (Look it up. It was ahead of its time.), and eat at a fancy restaurant called Chilis.

    So, maybe my brand recognition and a lifelong love of the grocery chain is stronger than most. There's no denying that it looms large over the health-food industry and is super-popular with upper-middle class soccer moms and those avocado-on-toast loving millennials we hear so much about (joke). How will Amazon leverage that loyalty? Could we see Amazon Fresh become “Whole Foods from Amazon”?

    It's Go time.

    The fourth and perhaps most compelling upside for the acquisition lies with Amazon Go, a recent experiment with automated retail stores.

    Go is a frictionless shopping and checkout experience for physical stores. According to their website, you just “browse and shop like you would at any other store. Then you’re on the way: no lines, no checkout.”

    Convenient.

    It's currently only open to Amazon employees in a single Seattle store but the idea is as simple as the implementation is complicated: use advanced scanners and trackers to automate checkout. But what does this do to labor cost? In their commercial, the lone store employee is making sandwiches. That's hyperbole, but it makes that point: this is what Amazon wants. Any labor that doesn’t directly enhance the customer experience is suspect and should be eliminated as soon as possible.

    Yesterday, outgoing CEO of GE Jeff Immelt scoffed that robots were not going to take over factory jobs in the next five years. Perhaps, but in retail, it has already begun. Many retailers from grocery stores to Home Depot offer self-checkout. If Amazon leads the way to friction-free checkout in supermarkets, retailers that do not follow in their footsteps will find that they’re the next Borders, CompUSA, or Radio Shack.

    The Go technology isn't ready for real world use yet but let's say it's at most 36 months away from being ready for prime time. That means that in relatively short order, Amazon can dramatically reduce one of the biggest expenses Whole Foods carries today: labor. They'll still have the cheese guy and the bread lady—those personal interactions are why people shop at a high-end grocer after all. Still, no more jockeying for the shortest checkout lines. It's hugely convenient, and it will happen.

    With Go, Amazon can now tackle Whole Foods’ biggest issue for most people: price. As much as I love it, my family doesn’t do our grocery shopping at Whole Foods. I have a great experience, but I need a second job just to pay the bill. In fact, I walk around with my iPhone out looking up pricing and even placing one-click orders on Amazon. Now, if I could get that Whole Foods experience at Amazon prices? Sign me up.

    Amazon will continue to do what they do best: leverage technology to remove inefficiencies in established industries, give customers the best possible experience along the way, and provide a shortcut to the things I want to do. This combination is their killer app.

    The Drupal Opportunity

    The opportunity for Drupal companies could be limited or could be huge. It seems unlikely that Amazon will continue to use Drupal to power their Whole Foods infrastructure in the long run. In the short run, however, Whole Foods will continue to operate as an independent, wholly-owned subsidiary—just with a lot more coverage and support from the most technically-savvy retail company around.

    Outside of the immediate timeframe, it could open opportunities to build closer ties to Amazon through the use of headless Drupal for backend data storage, retrieval, and integration. As much as retailers suffer from Amazon’s dominance, manufacturers benefit from frictionless distribution and additional sales channels that will be created. That gives us, the Drupal community, more opportunities to do what we do best with Drupal 8 and beyond. We can continue toward building voice interactions that tie into Amazon’s Alexa infrastructure in unique ways; Tech stacks that better integrate e-commerce platforms into Amazon’s listings and sales engine; and possibly even recruiting opportunities for top Drupal talent that may be winding down their tenure with Whole Foods.

    And that’s not even to mention the retailers that want to compete with Amazon head-on. They need what Drupal has: vision, community, and a platform for building world-class, sustainable, and expandable solutions. They need technology that allows them to meet and beat the Amazon at their own game. They need a shortcut to success, and that’s Drupal 8.

    Opportunities for Drupal from a mega merger of Drupal community companies.Planet Drupal, amazon.com, whole foods, drupal news
    This blog post is transcribed from the session "More Social, Less Media: Harnessing the power of Human Connection to Achieve Marketing Success" presented by Molly Nelson at Drupal Texas Camp in Austin, TX - June 2017 More Social, Less Media

     

    We know that you don’t want to lose news of Drupal. For that reason, and although it has officially started beach season, here you have the most interesting events of this summer.

    June 15

    One of the best parts of Drupal 8 is our shift to enterprise PHP coding structures. With tools like composer and Symfony’s structures like Events and Dependency Injection, Drupalists are learning to be great PHP developers, and vice-versa. Today, the fastest route to becoming a rock star Drupalist is through PHP.

    I’m one of the PHP track chairs for Drupalcon Vienna, and this year our focus is better PHP === better Drupalists. How can better PHP make your life as a Drupal developer easier?

    Do you like PHP 7? We want to hear about the technicalities of types, throwing all the things, and your favorite operators (mine is null coalesce, but full respect for you spaceship operator fans).

    Have you seen the light of functional programming? Tell us why we should love higher orders with lambda functions and closures. Let’s hear the finer points of first class functions.

    Do your tests bring all the bugs to the yard? We want to talk about it. Every method is a promise, and your tests make sure you keep your promises. We want sessions about test driven development in a drupal context, choosing the right test framework and scope, and how your real-world tests are saving you real-world time.

    Have you written a composer library wrapper module yet? Submit a session about how composer is saving you lines of code.

    Is your development environment fine-tuned for drupal excellence? Tell us how, and why.

    We have only two weeks left until session submissions close! Get your session in now and help us make Drupal code something to be proud of.

    The Contributed module Display suite (“DS”) allows you to take control on How do you want to render them using interface. admin has ability to arrange nodes, comment,user data, views etc. provides drag and drop after as we do for managing field section.

    If you want to build a drupal custom page and really don't have any drupal technical knowledge or coding skill or, you don’t want to write custom templates, and  for smaller stuff then you can go ahead with this Display Suite module. Is really helpful when it comes to replacing the default view of an entity to user defined view using application interface. It’s straightforward…

    Drupal’s Paragraphs module is a big part of what makes it easy for our clients to manage their site content. These three tips are how we make the user experience even better.

    Read More
    A recent prospect responded to my inquiry about the project budget with this:  "We can't release budget information as we need all vendors to bid their best price. If they know the budget they just bid right up to it."  

    When you are calling a function or method that has an argument(s), you don’t always know what type (array, object, string etc) of argument to pass to the function. And if you end up passing in the wrong type, you’ll get a less than helpful error.

    Lead Developer UK Conference 2017, Day 1

    On June 8 and 9, I attended the Lead Developer UK conference for the first time. Its unique format allowed us to learn about leading and motivating teams in the tech industry from experts.

    Josef Dabernig Thu, 06/15/2017 - 12:38

    The Lead Developer conference was my first non-Drupal conference in quite some time and I’m happy to write that I picked the right one. Not only could I learn and verify a lot of thoughts about leadership but it also gave me a new set of role models to be inspired by.

    The outstanding single-track program featured blocks of 3 sessions, most of them around 30 minutes with some shorter ones of around 10 minutes and some longer ones up to 50 minutes. Let me share a few of my personal highlights: 

    Patrick Kua – The Constant Life of a Tech Lead kicked off the conference by reminding us about the basics of leadership in tech and that we should focus on values and principles rather than tools or implementation details. People are unique, they differ and we need to find the right approach depending on the situation. It is especially important to help your team as much as possible by providing the necessary context to accomplish their goals, which is often forgotten in my experience.

    Constant Life of a Tech Lead from Patrick Kua

    Katherine Wu – Ask vs. Guess Culture Communication brought back the idea of how differently people “tick”. Are you a more upfront person that prefers a clear communication style with others, or are you more on the side that expects someone to read between the lines and work based on assumptions? I definitely find myself more on the guess culture side and knowing that this is not how everyone works already helps a lot.  

    Anjuan Simmons – Leadership Lessons from the Agile Manifesto gave a very personal track record of how he mastered leadership for himself and his teams. Working with a hero analogy, Anjuan mentioned that as tech leads we get called for the adventure, we get mentored with wisdom and are provided gifts to finally approach the boss level and return to improve the ordinary world. A tech lead guides other people on paths they have already taken. How does Anjuan motivate his team? At any cost, he will try to preserve the dignity of each team member and therefore earn their trust to together iterate and improve.

    Erika Carlson – Better: Fearless Feedback for Software Teams provided helpful insights for one of the topics I most struggle with: giving good feedback. Aside from the general feedback categories: positive to encourage and constructive to improve, there’s also a category that is often missed not considered. “Passive feedback” means that you don’t give feedback at all and that also mean something to your peers. Giving the right amount of feedback in time is critical to any healthy relationship. I also liked to find out about 360 feedback and the idea of having a dedicated #thanks slack channel to collectively practice appreciation.

    Better - Fearless Feedback for Software Teams from Erika Carlson

    Nickolas Means – The Original Skunk Works concluded the first day. It was a detailed look at the history of the aircraft manufacturer that showed what incredible achievements they could make based on Kelly’s 14 Rules. Providing a system to innovate and release quickly (continuous integration & deployments) was critical to the success of this team.

    The slides for all of the talks are available and I added the links to them above. On top of the inspiring talks, the conference had some more features I really liked too. Meri Williams was hosting the conference in a well-organized and entertaining way and followed up on a code of conduct issue in a constructive way. The conference also had a live captioning feature of all the talks on a screen, which helped me follow the massive flow of audio information and was even entertaining at times.

    At #leaddev conference in London today. All talks are live-captioned by @whitecoatcapxg, which is awesome. pic.twitter.com/KVcDdSsypu

    — Mehdi El Gueddari (@MehdiElGueddari) June 8, 2017

    Next week, let’s follow up with a summary of day 2 and conclusions for The Lead Developer UK conference.

    Drupal - simplytest.me, Evaluate Drupal Projects Online

    How to use simplytest.me, to evaluate drupal projects online?

    heykarthikwithu Thursday, 15 June 2017 - 08:50:40 - IST, Asia/Kolkata

    When you're running your non-profit, there is so much to do: basically an unlimited amount of work, right? Board meetings, fund-raising - and then there's the actual world-changing work you signed-up to do!

    Our ongoing series of helpful tips (click here to subscribe via e-mail) continues today with some help on how to efficiently manage one of the most common and important aspects of any non-profit: EVENTS.

    In this article, we'll talk about how to setup events in Drupal, and at the end, there's a video tutorial showing the process step-by-step.

    Read more to see how!

    Hi, my name is Jacob Rockowitz and I'm the individual responsible for maintaining the Webform module for Drupal 8. Two weeks ago, I posted Where Do We Come From? What Are We? Where Are We Going? documenting my journey and experience building and maintaining the the Webform module for Drupal 8. My goal was to document the current state of the Webform module, while simultaneously planning for the project’s future growth and sustainability. One of the steps toward accomplishing this is an idea I put together called "Sponsor a Feature".

    "Sponsor a Feature" is a process encouraging organizations to hire Open-source software maintainers and contributors to build features and fix issues that directly impact a company's project. Two key concepts behind "Sponsor a Feature": all work would be open source and the sponsoring organization would pay for tangible and immediate results directly to the working individuals.

    I feel that selling "Sponsor a Feature" to the Drupal community is going to be an uphill climb, especially because no one can technically sell Drupal. In other words, no one is used to paying directly for open source work. For now, I am going to tread lightly when talking about "Sponsor a Feature". For example, last week, I wrote about how Crowdfunding does not help grow Drupal's community to explore the different ways people are currently funding open source development. On Twitter, Adam Bergstein‏ (@n3rdstein) and I began a conversation about how an organization might pay a project maintain/developer.
    (https://twitter.com/n3rdstein/status/872856666114580482).

    Putting together an agreement that pays a developer to deliver...Read More

    Pathauto is a module which lets you automate the generation of URL aliases in Drupal. Instead of the URL being "/node/123", you can have "/blog/article/why-use-drupal". The module allows you to define custom patterns which are generated when an entity is created. URL aliases or URL slugs, help with search engine optimization and they're more user-friendly. Drupal core has supported URL aliases for a long time, but they weren't automatically generated. Pathauto helps with automating the process. In this tutorial, you'll learn how to create aliases and patterns, and how to bulk generate paths.
    What is Elevated Third, Denver Website Agency What is Elevated Third? Tony Dryer Wed, 06/14/2017 - 11:07

    Elevated Third’s namesake is rooted in company culture. It comes from the art world and refers to the experience one has when looking at a particularly moving or captivating piece of art. When you have a “get it” moment—that flash of understanding—an elevated third experience is created between the medium and you, the viewer.

    At Elevated Third, a Denver website agency focusing on Drupal, we strive to replicate this experience for our clients, our partners, and our employees.

    Our Culture 

    Our culture and work ethic is based on an idea that the right environment can foster incredible talent. We don’t exclusively hire people who fit a job description, instead we hire people who are smart enough to grow into their own description. We choose employees based on their aptitude to overachieve. Then, we observe. We figure out what said employee is particularly good at and we create a job description around their strengths.

    This practice is easier said than done. It requires a scaffolding of actionable core values and exceptional hires who allow their peers to be vulnerable. Because, of course, learning means making mistakes.

    Ultimately, it is an environment of support, vulnerability, and observation that allows us to foster talent instead of hire it based on a list of requirements and a resume. The results: employees who feel important, who produce great work, and who are happy to work hard.

    On top of all the standard agency perks like snacks and foosball, our new core values are essential to establishing and maintaining our internal culture here at Elevated Third. They are the guidelines for personal success. Following them is the best way to be successful at our Denver website agency. When our employees are successful, the company will prosper. Establishing the core values in late 2016 has had a direct impact on the business success we have seen thus far in 2017.

     

      Core Values

    When we first got together to determine our core values, we knew it was not going to be a simple process. We had to get it right, and we had to take the time to carefully craft each value.  

    We started by listing attributes that we believe make our employees successful. Things like accountability, effectiveness, work ethic, engagement, curiosity, positive energy, empathy, confidence, and thoughtfulness to name just a small sampling. For the next few months, we boiled down our list and crafted them into similar groupings. From these groups, the five values that we have now started to make themselves clear. It was a long, sometimes tedious, yet fulfilling experience.

    The Elevated Third Core Values:

    • Start with empathy. Respect and honesty come first. Care about our clients, our users and each other.
    • Lean in and keep moving. Stay engaged, positive and persistent. Bring energy and never quit.
    • Make an impact. Seek out and solve the right problems. Be fearless! Fight for the win-win.
    • Be a remarkable player. Put the team first. Step up when it’s time, inspire by example.
    • Own the outcome. Take responsibility for results. Embrace data celebrate effectiveness and face failures. Never stop improving.

    The core values we have put in place guide all the decisions we make within our Denver website agency. They help inform everything from questions in an interview process, project decision making, peer to peer feedback, internal growth strategy, and long-term client relationships. Every single aspect of the business can be applied to the five core values. Since implementing them we are seen our decision-making process become much more focused, both short term and especially long term.

     

     

    We’ve made an initiative out of preventing the typical cliched core value design. Figuring out creative ways to implement them into our everyday process has become a necessary challenge. We specifically seek out the traits that the values exemplify in our hiring process. In addition, all new hires see the exact debut presentation our company founders shared during the core values unveiling meeting.

    Our core values are meant to stand against the core value bandwagoners, they run through our day-to-day, our hiring, and our attitudes.

    Each and every day, we’re seeking the elevated third experience.

    Kiev Drupal Camp 2017: The First Impression root Wed, 06/14/2017 - 16:35

    I took part in Kiev Drupal Camp 2017 last weekend. It was a good decision to go to the code sprint. I'm sure that the second day of the conference was much better than the first one with formal presentations. My personal thanks to Dmitry Drozdik, Dmytro Danylevskyi and Alexander Schedrov for their help to meet OpenY.

    The main issue of the first day was that presentations went in several 4-5 streams in different rooms and I missed a lot of useful information. Fortunately, Conference organizers recorded videos of all presentations.

    On this Camp I had presentation: Paragraphs are more powerful than you can expect.

    There was not enough time. I tried to provide the extended overview and 3 demonstrations, but overview was very short and demos weren't very attractive. There is the video above.

    Also you can download PDF with slides by the link http://abzats.com/kiev17.pdf

    Planet Drupal LandingPage Drupal 8

    آخرین ارسال ها

    محتواهای محبوب

    درباره ما

    Author
    اینجا دروپال یعنی همه چیز. در مورد دروپال صحبت میکنیم. ماژول هامون رو به اشتراک میزاریم در مورد قالب دروپال ، فروشگاه دروپال، دروپال فارسی و تاریخ شمسی دروپال صحبت میکنیم و هرچیزی که در مورد طراحی سایت با دروپال میدونیم به هم انتقال میدیم. دروپالیون یک سایت شخصی نیست. ما دست همه کسانی که برای پیشرفت دروپال تلاش میکنند رو میفشاریم و با آغوش باز اونها رو در این سایت میپذیریم.

    تماس با ما

    با ما تماس بگیرید.

    logo-samandehi