Newsfeeds

Entity Type Class

New Drupal Modules - 3 August 2017 - 11:13am

Provides a plugin based system to alter entity type classes. It currently support overriding Node, User and File entity type classes.

Categories: Drupal

Drip Marketing Automation

New Drupal Modules - 3 August 2017 - 10:14am

This module integrates Drip (drip.co) with Drupal. Drip is marketing automation software.

All you need to do is enable the module and add your Drip ID in the configuration page.

Future

More features and a roadmap will be added soon.

Categories: Drupal

agoradesign: Drupal quick tip of the day: react differently to CLI calls

Planet Drupal - 3 August 2017 - 5:04am
Sometimes you want to react differently, when the current script is running in a command-line environment. Here's how you can do this.
Categories: Drupal

Appnovation Technologies: How I Stepped My Way Through a Failing Drush Drupal 8 Migration With PHPStorm’s Xdebug Integration...PART 1 of 2

Planet Drupal - 3 August 2017 - 4:37am
How I Stepped My Way Through a Failing Drush Drupal 8 Migration With PHPStorm’s Xdebug Integration...PART 1 of 2 I was recently going through the d8cards set of exercises to test my knowledge of Drupal 8 APIs, as one does in the dev world... Put simply, or as simply as possible, it consists of a set of 21 exercises, each going over a common Drupal task and how it changes from Drup...
Categories: Drupal

Deeson: Reflections on organising DrupalCamp Bristol 2017

Planet Drupal - 3 August 2017 - 2:57am

Photo credit: Kris Rzeszut

DrupalCamp Bristol is a non-profit event organised by a team of volunteers from the Bristol Drupal community.

This year, the organising committee chairperson was Mark, a solutions architect at Deeson.

In this post, he considers the challenges and rewards of being involved in organising a community conference. Post-event reflection

After another intense year of planning we’ve just run DupralCamp Bristol for the third time.

It was a really enjoyable few days and we had some great feedback from attendees.

@DrupalCampBris Thanks to all who made #dcbristol17 such a great experience. Inspiring stuff. Looking forward to next year already! :)

— Alison Bancroft (@BancroftAlison) July 2, 2017

Though that’s not to say the experience was entirely stress-free for the organisers!

The challenges

We noticed a shift this year in the way our audience considers the conference. Rather than spending their own time (and money) to attend, people are increasingly opting to make use of company-provided training time and budgets.

It’s great that attendees and their employers see the business value in what DrupalCamp Bristol provides, but it did make organising this year’s camp (on a Saturday) more tricky.

Sponsorship was another area we had to put a lot more of our energy into, compared to previous years. We worked hard to demonstrate the value of spending marketing budget on sponsoring the event, and we were glad to secure the support of some great partners this year, including Deeson.

The positives

Speaker and attendee diversity was a priority for us this year, and we’re proud that our line-up was more representative than in previous years. We know we still have a long way to go and, like Deeson, it’s something we’ll keep actively working on.

A particular highlight for me this year was the lightning talks. It was exciting to witness new talent making, in some cases, their first public speaking appearances in front of the community.

This was also the first year we’ve been able to record all of the sessions, thanks to the hard work of Third Lens Films. Deeson is working on the video post-processing as we speak, and we’ll be publishing the videos in the next few weeks for everyone to enjoy.

How could we improve?

While we’ve received positive feedback year-on-year for the CxO day, I feel like it’s ultimately drawing our attention away from the main conference and would be better suited as an independent event if there is still a demand for it. This would allow us to really focus our energies on organising a fantastic developer conference.

Developers have lives outside of Drupal and companies are increasingly seeing the business value in training events, so I’m confident we would see a surge in attendees if we follow the lead of other technology conferences such as The Lead Developer and move away from running the conference over a weekend.

It’s a lot of work organising the conference, and it couldn’t happen without the hard work and dedication of the committee and volunteers – I’ve particularly appreciated Deeson’s flexible working policy over the last few months! – but something I’m always glad to be part of. Roll on the next one!

Work with Drupal? Deeson is currently hiring for several roles in the development team!

Categories: Drupal

Amazee Labs: Our React learning journey

Planet Drupal - 3 August 2017 - 12:39am
Our React learning journey

If you push yourself enough with the right amount of motivation, you can achieve more - this notion, along with a lot of curiosity, is what got us through the journey of learning React and helped us to continuously improve the code as we worked on getting the Cape Town Drupal Camp website up and running. 

Maita Kambarami Thu, 08/03/2017 - 09:39 How we started

Like most of our websites at Amazee we first sat down with the design team, to get a clear vision of what their design for this specific project entailed. The design was beautifully crafted and very intuitive to bring out the whole purpose of the Drupal Camp.  

We had an intense briefing meeting, where a lot of sharks and unicorns were mentioned, and at the back of my mind, I had this niggling thought “how is this all going to be done with React” but eventually I hashed my limiting thoughts to focus on the job ahead.

Scrum meeting

During round two of the process, the DBB Scrum Team met for their project planning. These discussions are an agile sort of thing where we go over the estimates and plan how to build the website. We were lucky that Stew had attended the React in Flip Flops training week earlier this year, so he was a good guide and help for most of the things we struggled with.

Before we could plunge into the development of things we had to plan which of the elements qualified to be components, and herein then we encountered our first great learning curve.

The real struggle

There are many bits of advice floating around out there on the best way to learn code, and then more specifically, React. This includes tutorials, in-house knowledge sharing with other team members, reading others’ code with great attention, and blog posts.

Even though tutorials don't always help you the way you expect them to, they do however open your eyes to have an idea of what you hoping to learn. I remember going through Kirupa’s  tutorials and afterwards realising that the way he explained React did indeed open my mind a little more.

Since we were not using React Native I had to rely more on our in-house knowledge share. These regular React knowledge share sessions within the team helped us get some good insight of React and styled components. As a team, we created a Todo App with Facebook’s Create-React-App and went through the code line by line to learn and understand better.

A lot of people say to learn and understand code you have to read other people‘s code not just follow tutorials. The aim is to try to understand things from their point of view and so that's what we did, we closely followed a decoupled Drupal site that our Zurich team is working on at the moment.

There is also a good blog post by Dries Buytaert where he explains the future of decoupled Drupal and gives alternatives to the technologies that can be used to achieve this. In his blog, he mentions our very own Sebastian Siemssen and regards his approach to use GraphQL, as one of the best and gives reasons why.

Tools that help out the workflow

We used a variety of tools in our workflow, two of which are lint-staged and Jenkins, working with these tools also helped us to learn a lot of lessons along the way. A linter is a tool that checks your code for potentially dangerous patterns. It also helps with the consistency of your codebase by checking, for example, the use of indentation and other spacing. It helps you catch silly typos or leftover variables as you go.

Jenkins, on the other hand, is an open-source continuous integration software tool, which we use to automate deployments to our dev, staging and prod servers.

We chose to use styled components as our styling method.  There are some other libraries that one can use a good comparison can be found here.

Some examples:

The way we build the Section Title.

Since all the sections had a title we created one Section Title component that could be reused inside the other sections.

This is the section title in yellow --

Then the code

We created a Section Title Component with {title}, {sectionID} and {titleClasses} as props  (property Types) that were passed  down to the SecTitle as className={titleClasses} , id = {sectionID}  and the {title} . The Section Title component displays the title of the section, along with the id and className whenever it is called.

Importing the Section Title

Below is how the Section Title will be imported and used in the other sections.

The Section Title component is called and the title and the ID are defined. So it will be <SectionTitle title= “Call for speakers” sectionID= “callforspeakers”>.

Notice the className is not used here, and only the title and the ID are used.  You can choose not to use all the property types depending on what you want to achieve.

SectionTitle used without the title property type:

Another example

How we used the mapping function to output a list of sponsors.

What we did here is to create a SponsorList component, which manages the type and the sponsors, by mapping each SponsorsListArray to the type of sponsor.

We created the SponsorsItem component to be used by the SponsorsListArray.

Then we created an array of SponsorItems. Below are three arrays: 1. sponsorsListArrayGold, 2. sponsorsListArraySilver and 3. sponsorsListArrayInKind.

So, each array will have a list of sponsors for that particular type.

For the mapping part

A SponsorsList component will receive a { type } as a parameter and use the else if statement to output the code according to the parameter given.  

So if {type}  = gold then...

It will return a list with SponsorListArrayGold. Another point to remember and make a note of is the use of spread operators, which we used to avoid mutating the props objects.  

So, instead of copying the props one by one we just used {...sponsors}. If more props are added to the SponsorItem there will then not be any need to add it inside the SponsorList Component.

The final index.js of the parent component looks like the code snippet below.

The two SponsorsLists have type gold and silver respectively passed to it, so the type property determines which SponsorListArray is going to be returned.

Conclusion

Our next step would be to learn how to connect React front end to Drupal backend. We will most probably take the Graphql route and maybe write another detailed blog about it.

Like I said, during this project we learnt through trial and error as we went through the various stages. After we fully harnessed the power of React components, we had a better picture of what needed to be done and how to do it.  It also meant that we were able to create elements a bit faster. This was all possible, working as a team and reusing and enhancing components that were already built to produce the best website we could.

See the site at https://capetown2017.drupalcamp.co.za/

Categories: Drupal

Pages

Subscribe to As If Productions aggregator