Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 31 min 28 sec

OSTraining: New Video Class: phpMyAdmin

lun, 13/07/2015 - 16:06

Here at OSTraining we teach Drupal, Joomla, WordPress and touch on other platforms such as Magento. All of these platforms use MySQL as their default database.

phpMyAdmin is free software written in PHP, intended to handle the administration of MySQL. phpMyAdmin is a very reliable tool when you need to directly access the data in your database.

Catégories: Elsewhere

ThinkDrop Consulting: A Call to Action: Aegir, The Next Generation at NYCCamp 2015

lun, 13/07/2015 - 15:42
Aegir Summit & DevOps Camp at NYCcamp 2015

This Thursday starts NYCcamp, which is gearing up to be a huge event.

This year they've expanded even more beyond Drupal to all free & open source technologies.

Most important to us at ThinkDrop is the first ever Aegir Summit. Most of the Aegir maintainers will be there discussing all of the cool things we are doing with it, and where to go from here. For the full schedule and to register, see http://nyccamp.org/summit/aegir-summit.

On Thursday is an Aegir Site Factory training session.  The main Aegir Summit takes place on Friday

Aegir: The Next Generation

This event is going to be a turning point for the Aegir project.  Three of the maintainers, Christopher Gervais, Cameron Eagans, and myself met at DrupalCon Los Angeles over lunch to discuss what to do next with the project.

We all agreed that there are many issues with Aegir as it stands. We saw that containerization was going to be the way to go in the future.  We all agree that Aegir is so monolithic, so complex, and so full of legacy code that it might be easier to just start over using modern tools like symfony, ansible, and docker.

We even agreed that we (might) need a new name.

From this, Cameron wrote up the Aegir NG proposal on hackpad so we could all contribute our ideas.

At the Aegir Summit, we will be having a panel discussion to present these ideas to the community and get feedback on where to go from here.

I urge all of you to attend, or keep tabs from afar.

The Future of Open Source Hosting

We know that many, many people need the promise of Aegir: easily deploy and update sites at scale. We all know that Aegir has many problems with delivering this promise

We know that outside of it's rather die hard fanbase, Aegir is not really well liked because of these problems.

If you are one of those people, I urge you to join the Aegir Next Generation cause.  We are going to fix Aegir for good, and we need your help.

Registration Ends Tomorrow!

Registration for Aegir training ends today, Monday July 13 at midnight ET. Registration for the Aegir Summit ends Tuesday, July 14 at midnight ET.

If you are attending NYCcamp, please register for the Aegir Summit. Even if you can only attend the panel, I promise you, it will be worth it!

Register for Aegir Summit at http://nyccamp.org/summit/aegir-summit.  Register to attend the "Open Agency Site Factory" training at http://nyccamp.org/training/open-agency-site-factory-ops-freedom-aegir

Tags: aegirnyccampdevshopPlanet Drupal
Catégories: Elsewhere

Microserve: Organising a DrupalCamp - Tips and feedback from DrupalCamp Bristol 2015

lun, 13/07/2015 - 15:19

As the Chair of the DrupalCamp Bristol Committee, I thought it would be great to share what I took away from organising Bristol's first DrupalCamp. I'm sure there's a few things to be learnt from this, and if not then at least it will make an interesting read!

The Figures

Friday total sales: 74
Friday turnout: 64

Saturday total sales: 132
Saturday turnout: 109

Income (to be finalised): £12,805.00
Expenditure (to be finalised): £11,964.16

I'd be happy to share the figures with any new camp organisers, and answer any questions you might have - simply drop me an email.

A big thank you would also be appropriate at this point to Kris Klinkhammer for all her help at the Drupal Association.

What went well?

The actual camp weekend was fantastic and we received a lot of great feedback. We had picked two amazing venues and a summer date, and luckily for us the weather did not disappoint; we even had lunch served outside!

We were worried at first when we realised we had to choose a different venue for each day, but in the end I think that worked out in our favour. St George's Hall in particular was a fantastic choice as our attendees were delighted to see the event held in such a unique venue, and started the weekend off in very high spirits.


- St Georges Hall: www.stgeorgesbristol.co.uk/venue-info/

A decision I’m glad we made was to introduce a Drinks Sponsor as a tier between Organisational and Gold Sponsors. Their fee was £1,000 which was put directly behind the bar of a superb venue - Goldbrick House - which was directly behind St George’s Hall. This decision had two advantages; not only were we not handling any cash, and therefore not subject to the 10% DA fees, but a bar tab of that size is a great way to ensure that all your attendees carry on late into the evening which creates a great networking opportunity.

At the core of the event we also had a fantastic variety of talks, so a big thank you to each and everyone of them.


- Léonie Watson giving her Saturday keynote on "The metamorphosis of accessibility"

We were also pretty lucky with the committee, since we had a total of 9 people and it meant no need for any other volunteers over the weekend. We used Trello for communication (separating a board for each key area) and had monthly meetings at the Microserve offices to ensure everything was on track.

Little tip: The initial meetings will be long. Get some rules in place, figure out how to make quick decisions, elect a chair early. The first few meetings were twice as long as the others, so get a few Pizza's expensed!

What didn’t go so well?

We had initially attempted to have a sub-event on each day; Training would be held on the Friday within the same venue, and Sprints would be held on the Saturday. Unfortunately we barely sold any Training tickets so we had to cancel this, and although we had a great room for the Sprints, we simply didn’t publicise this enough and therefore it was barely used. We'd have liked to invite more people to sprint by giving them a free ticket, but because the sprints were in the same place as the camp, we had to acknowledge that each person would still be subject to the same "per head" cost - food & drink, t-shirt, merchandise etc - so we didn't do this unfortunately.

I should also thank Circle Interactive who provided us with a great deal on training. Although we weren’t at a financial loss by cancelling it they had put their time into putting something together and they were very understanding when we cancelled.

Where could we improve?

What are the main points I'll be taking into year 2 and what is my advice to anyone approaching their first DrupalCamp?

Take things easy on year one

We thought we had adhered to this rule by not having a Sunday conference day, but we should have also applied this to Training. We do look forward to putting a heavier focus on that next year though!

Don’t think of everything as linear

We didn’t start selling tickets till the website was complete, we didn’t start on the website till we had agreed all the key information and we didn’t promote to speakers and sponsors till we had all details. In hindsight we could have taken a much less linear approach, which would have boosted sales early and got our speakers and sponsors on-board faster.

There's a couple of points I should empahsise on the back of this one: 

  1. 8 months planning will suddenly catch up with you when you're 2 months away from the event and the ticket sales aren't what you expected. It really is important to not feel too comfortable in the early stages, and to get tickets and speaker requests out early.
  2. DrupalCamp already has a name for itself, so early bird tickets will sell regardless. We could have tweeted about early bird tickets before we even had the venues or any detail sorted; as long as the date is confirmed there'll be an audience who are happy to snap the tickets up without knowing the finer details!
Improve communication groups

We had email groups so everyone received everything (such as contact form submissions and EventBrite queries), yet it wasn’t always clear whose job it was to reply to certain things. One example here is sessions submissions which arrived via the website; it took a few weeks before somebody stepped up to manage this and confirm all the submissions, which really was hassle we could have avoided. As soon as someone offers to talk, get it confirmed asap!

Pass responsibility on better throughout the process

It was good that all the team found sponsors and speakers, but we continued communication this way instead of passing communications on to the appropriate team member. If we were chasing payments, logos, or session info for example, we would ask the connected individual to do it as opposed to the person whose role it was to look after sponsors or speakers.

Accept you will use discount codes, and put these into your marketing strategy

Admittedly this is the one thing I completely overlooked, as we had only thought about early bird Saturday tickets. We ended up creating a variety of discount codes which didn't really follow any plan, and became a little bit messy. We sent out camp specific discount codes to Brighton and London which was a nice gesture, but in the final month when we felt numbers were lagging a bit for the business day we ended up giving our speakers and sponsors heavily discounted ticket codes to pass on to other team members and friends. Although this worked to an extent, it didn't follow any structure and we ended up having a couple of refund requests from attendees who purchased full price tickets and felt a bit hard done by.

Sessions and Speakers

Not surprisingly we had a great variety of feedback on this, both positive and negative. We also asked "What topics / speakers would you like to see at a future DrupalCamp?" so we now have some great feedback to help shape our next camp.

From an organisers point of view one of the largest problems we faced was a lack of gender diversity amongst speakers. I should clarify that although we were lucky enough to secure Léonie Watson for the Saturday keynote, there wasn't a single session submitted by a female speaker, which was really a shame. 

I could probably write a whole post covering this area, so I'll go into more detail on how we are trying to be more inclusive for DC Bristol 2016 in another blog post at a later date.

How did you think it went?

We want to thank each and every person who attended the event, and we'd also like to ask for your feedback in order to make next year bigger and better.

We have a link to a survey hosted on Survey Monkey here. We would very much appreciate it if you could give us your feedback!


- People enjoying lunch outside in the sun


- The DCB 2015 Committee (minus Jon Hadley)

Rick Donohoe
Catégories: Elsewhere

Dries Buytaert: Acquia announces it is ready for Drupal 8

lun, 13/07/2015 - 15:02

I'm excited to announce that starting today, Acquia is announcing we're ready to fully support our customers with Drupal 8. This means our professional services, our support, our product engineering, our cloud services … the entire company is ready to help anyone with Drupal 8 starting today.

While Drupal 8 is not yet released (as it has always been said, Drupal 8 will be "ready when it's ready"), the list of release blockers is dwindling ever closer to zero, and a beta-to-beta upgrade path will soon be provided in core. These factors, along with Acquia's amazing team of more than 150 Drupal experts (including a dedicated Drupal 8 engineering team that has contributed to fixing more than 1,200 Drupal 8 issues), gives us full confidence that we can make our customers successful with Drupal 8 starting today.

In the process of working with customers on their Drupal 8 projects, we will contribute Drupal 8 core patches, port modules, help improve Drupal 8's performance and more.

I'm excited about this milestone, as Drupal 8 will be a truly ground-breaking release. I'm most excited about the architectural enhancements that strongly position Drupal 8 for what I've called the Big reverse of the Web. For the web to reach its full potential, it will go through a massive re-platforming. From Flipboard to the upcoming release of Apple News, it's clear that the web is advancing into the “post-browser” era, where more and more content is "pushed" to you by smart aggregators. In this world, the traditional end-point of the browser and website become less relevant, requiring a new approach that increases the importance of structured content, metadata and advanced caching. With Drupal 8, we've built an API-driven architecture that is well suited to this new “content as a service” approach, and Drupal 8 is ahead of competitive offerings that still treat content as pages. Check out my DrupalCon Los Angeles keynote for more details.

Catégories: Elsewhere

Annertech: Integration patterns for connecting your website with your CRM

lun, 13/07/2015 - 14:26
Integration patterns for connecting your website with your CRM

Previously we wrote about connecting your website with external systems, and specifically, the benefits of connecting your site with your CRM . As with many problems, there are many ways to approach this.

Catégories: Elsewhere

Drupal core announcements: Drupal core security release window on Wednesday, July 15

sam, 11/07/2015 - 01:56
Start:  2015-07-15 (All day) America/New_York Online meeting (eg. IRC meeting) Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, July 15.

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, August 5.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Catégories: Elsewhere

Forum One: See You at NYC Camp from July 16-19!

ven, 10/07/2015 - 17:46

The Forum One team is thrilled to be heading to the United Nations for this year’s NYC Camp. We’re looking forward to seeing both new and familiar faces, and sharing some of the newest things the team’s been working on in terms of data visualization, Drupal development, and automation.

Here is a look at the sessions we’ll be leading:

The Drupal 8 Decision: Budgets, Bosses, and Bul@#$% Standing Between You and the Next World-Class CMS

Drupal 8 is coming. When we reach “Issue Queue Zero,” your business or organization needs a sensible strategy for upgrading your sites to D8. There are variety of questions to consider including available talent, budgets, goals, and aspirations. This session will be of particular interest to executives, business owners, nonprofit professionals, communications staff, and site managers who face this increasingly pressing decision regarding D8.

Building Realtime Applications with Drupal and Node.js

Call it the “appification” of the web. Users’ expectations are being pushed in the direction of being able to interact with sites and content not by clicking a link or refreshing the page but by having those changes come directly to them. We’ll be using Drupal, AngularJS and Sails.js to demonstrate the capabilities of both Javascript and Node to build interactive applications and synchronize with Drupal through the REST interface to serve as the data repository.

Automating Deployments

That moment when new code makes it way out into the world is the most fragile part of the process. We take for granted all the steps that need to happen to make sure it goes correctly. In this session we’ll be demonstrating technologies to turn deployments from a nail biting experience into a simple “one click and done.” You’ll see the power of Jenkins to manage the continuous integration process and Capistrano to deploy changes and how to drive it all from changes in your git repository.

D3 Data Visualization: Because your data should tell a story

There’s no escaping the fact that data visualization is hot right now. Everyone wants to tell their data’s story visually, whether it be through a map, chart, or more detailed presentation. The difficulty is there are so many different tools that solve this, each one with their own benefits and limitations. We feel D3.js is the most awesome tool for handling this task — which is the approach we’ve used for the sites like the Nation’s Report Card, BlueCross BlueShield of North Carolina, GlobalChange, and others.

Drupal 8 Theming with Twig!

Prepare yourself with the skills you’ll need to hit the ground running as a Drupal 8 themer. This training will be a hands-on, an interactive workshop where we will build a Drupal 8 theme from the ground up using Drupal 8’s new template engine, Twig.

We will recommend best practices around template logic, determining what should be themeable output in the first place, leveraging theme suggestions and reusable theme components, overriding and extending templates, and more. We will also talk about why themers should be excited for the tools that contrib can provide in Drupal 8.

This workshop is intended for Drupal themers and front-end developers. Knowing the basics of git will be helpful but is not necessary. No PHP knowledge is necessary but a laptop is required.

Twig is being improved in Drupal 8 Core @ http://drupaltwig.org/ and you are all welcome to join in and help make Drupal 8 theming awesome!

 

Catégories: Elsewhere

Drupal Watchdog: Know Your Audience

ven, 10/07/2015 - 17:24
Article

Drupal.org is one of the largest and oldest continuously-operating Drupal websites in the world. The amount of content we have is both a blessing and a curse. Historically developed and maintained by community volunteers, Drupal.org has been growing organically for over a decade. New content keeps being added, while no major changes to information architecture and navigation have made it easily findable. With about 1.2 million pieces of content, the need to overhaul Drupal.org has become obvious. But where do we even start?

It is tempting to jump straight into content strategy, kick off a massive content audit, and talk about content types and archival processes. However, to develop comprehensive content strategy, you need to understand what kind of content is actually needed on your site. And to understand that, you need to know your audience.

Researching the Users

We underwent a user research project which lasted from May to August of 2014. Through a public request for proposal (RFP) process, we partnered with Whitney Hess, a user experience coach, to help guide the Drupal Association staff and community volunteers through the research.

The project kicked off with a full-day workshop at DrupalCon Austin. Participants included representatives from the Drupal Association staff and the Board of Directors, community volunteers, and advisors. Together, we brainstormed objectives for the new Drupal.org and metrics of success, as well as provisional user personas – our ideas about what those personas could be.

With that groundwork in place, we set out to validate (or disprove) our assumptions with real people.

We talked to 30 different users of our website located in the Americas and Europe: people who were new to Drupal, long-term community members, ex-Drupalistas, developers, site builders, designers, content strategists, PMs, and more. We sat down for an hour with each one of them and asked numerous questions about the way they use Drupal.org, things they enjoy about it, and their frustrations.

Once we had the data from the interviews, we started to synthesize it and develop personas.

Catégories: Elsewhere

Drupal core announcements: Recording from July 10th 2015 Drupal 8 critical issues discussion

ven, 10/07/2015 - 12:10

This was our 7th critical issues discussion meeting to be publicly recorded in a row. (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:21am] berdir: pfrenssen: that's one scary profile picture ;)
[11:22am] pfrenssen: haha it zooms in nicely :D
[11:23am] jibran: berdir: yay! https://bugs.php.net/bug.php?id=69996&edit=1 got fixed.
[11:26am] jibran: https://www.drupal.org/project/issues/search/drupal?status[0]=1&status[1]=13&status[2]=8&status[3]=14&status[4]=4&priorities[0]=400&categories[0]=1&categories[1]=2&categories[2]=5&version[0]=8.x
[11:27am] jibran: https://www.drupal.org/node/2497243
[11:27am] Druplicon: https://www.drupal.org/node/2497243 => Rebuilding service container results in endless stampede [#2497243] => 139 comments, 34 IRC mentions
[11:27am] GaborHojtsy: jibran: that’s the one that Fabianx-screen is talking about, right? :)
[11:29am] Fabianx-screen: Issues I talked about:
[11:29am] Fabianx-screen: https://www.drupal.org/node/2529516
[11:29am] Druplicon: https://www.drupal.org/node/2529516 => Decouple tests from relying that $container is a container builder [#2529516] => 10 comments, 9 IRC mentions
[11:30am] jibran: https://www.drupal.org/node/2502785
[11:30am] Druplicon: https://www.drupal.org/node/2502785 => Remove support for $form_state->setCached() for GET requests [#2502785] => 119 comments, 23 IRC mentions
[11:30am] jibran: https://www.drupal.org/node/2505989
[11:30am] Druplicon: https://www.drupal.org/node/2505989 => Controllers render caching at the top level and setting a custom page title lose the title on render cache hits [#2505989] => 54 comments, 10 IRC mentions
[11:30am] pfrenssen: I can't talk
[11:30am] Fabianx-screen: https://www.drupal.org/node/2530586
[11:30am] Druplicon: https://www.drupal.org/node/2530586 => Read-Only Container is not working properly. [#2530586] => 0 comments, 4 IRC mentions
[11:30am] pfrenssen: nice construction noises :)
[11:30am] pfrenssen: https://www.drupal.org/node/2524082
[11:30am] Druplicon: https://www.drupal.org/node/2524082 => Config overrides should provide cacheability metadata [#2524082] => 82 comments, 24 IRC mentions
[11:31am] pfrenssen: That's what I am working on. Next steps are to address the last remarks.
[11:31am] pfrenssen: It's clear how to move forward.
[11:31am] GaborHojtsy: pfrenssen: :)
[11:32am] jibran: https://www.drupal.org/node/2525910
[11:32am] Druplicon: https://www.drupal.org/node/2525910 => Ensure token replacements have cacheability metadata and that it is bubbled in any case [#2525910] => 72 comments, 10 IRC mentions
[11:32am] jibran: https://bugs.php.net/bug.php?id=69996&edit=1
[11:33am] GaborHojtsy: https://www.drupal.org/node/2512718
[11:33am] Druplicon: https://www.drupal.org/node/2512718 => EntityManager::getTranslationFromContext() should add the content language cache context to the entity [#2512718] => 144 comments, 46 IRC mentions
[11:35am] GaborHojtsy: https://www.drupal.org/node/2529516
[11:35am] Druplicon: https://www.drupal.org/node/2529516 => Decouple tests from relying that $container is a container builder [#2529516] => 10 comments, 10 IRC mentions
[11:37am] jibran: https://www.drupal.org/node/2528178
[11:37am] Druplicon: https://www.drupal.org/node/2528178 => Provide an upgrade path for #2354889 (block context manager) [#2528178] => 36 comments, 7 IRC mentions
[11:40am] jibran: https://www.drupal.org/node/2454439
[11:40am] Druplicon: https://www.drupal.org/node/2454439 => [META] Support PHP 7 [#2454439] => 126 comments, 25 IRC mentions
[11:40am] berdir: jibran: http://d8php7bot.erwanderbar.de/
[11:42am] pfrenssen: yay! :D
[11:42am] GaborHojtsy: dawehner: alexpott: we are running out of topics to talk about :D any topics you wanted discussed while we are on the call?
[11:42am] GaborHojtsy: dawehner: alexpott: https://plus.google.com/hangouts/_/gspzs5s25ucfasw6puf7muif7ya
[11:43am] alexpott: GaborHojtsy: yep
[11:44am] jibran: https://www.drupal.org/node/2505989
[11:44am] Druplicon: https://www.drupal.org/node/2505989 => Controllers render caching at the top level and setting a custom page title lose the title on render cache hits [#2505989] => 54 comments, 11 IRC mentions
[11:45am] dawehner: GaborHojtsy: oh let me try to join
[11:45am] GaborHojtsy: dawehner: alexpott is discussing title filtering
[11:45am] alexpott: https://www.drupal.org/node/2530474
[11:45am] Druplicon: https://www.drupal.org/node/2530474 => Discuss whether => 0 comments, 1 IRC mention
[11:46am] • dawehner tries to join again
[11:49am] dawehner: alexpott: GaborHojtsy I can't talk probably (given the speed of the net, can kinda listen) but I think allowing is a thing, given that people wanted something like tags
[11:57am] jibran: https://www.drupal.org/node/2493911
[11:57am] Druplicon: https://www.drupal.org/node/2493911 => Update guzzle, goutte and mink-goutte-driver to the latest release [#2493911] => 76 comments, 2 IRC mentions
[11:58am] jibran: https://github.com/guzzle/guzzle/pull/1167
[11:59am] pfrenssen: yay! D:
[12:00pm] pfrenssen: 14
[12:00pm] dawehner: https://www.youtube.com/watch?v=P_yl2WuiW4g
[12:00pm] pfrenssen: have a nice weekend!

Catégories: Elsewhere

KatteKrab: Landscape design: a great analogy for the web

ven, 10/07/2015 - 09:16
Friday, July 10, 2015 - 17:16

I often find myself describing the digital domain to people who don't live and breathe it like I do. It's an intangible thing, and many of the concepts are coded in jargon. It doesn't help that every technology tool set uses it's own specific language, sometimes using the same words for very different things, or different words for the same things. What's a page? A widget? A layout? A template? A module, plugin or extension? It varies. The answer "depends".

Analogies can be a helpful communication tool to get the message across, and get everyone thinking in parallel.

One of my favourites, is to compare a web development project, to a landscape design project.

One of the first things you need to know, is who is this landscape for and what sort of landscape is it? The design required for a public park is very different to one suitable for the back courtyard of an inner city terrace house.

You also need to know what the maintenance resources will be. Will this be watered and tended daily? What about budget? Can we afford established plants, or should we plan to watch the garden grow from seeds or seedlings?

The key point of comparison, is that a garden, whether big or small, is a living thing. It will change, it will grow. It may die from neglect. It may become an un-manageable jungle without regular pruning and maintenance.

What analogies do you use to talk about digital design and development?

Image: XIIIfromTOKYO - Plan of the gardens of Versailles - Wikipedia - CC-BY-SA 3.0

Catégories: Elsewhere

Drupal CMS Guides at Daymuse Studios: Elegant Drupal 7 Administration: Mobile Theme, Menu, Modules

ven, 10/07/2015 - 01:29

Use this system of Drupal admin theme and modules to create a mobile-friendly, modern Drupal 7 administration user experience. Improve workflow, help users.

Catégories: Elsewhere

Acquia: Front End Performance Strategy: Scripts

jeu, 09/07/2015 - 21:31

In the last installment of this series, we considered CSS optimization. This time we’re going to look at the impact of scripts.

Remember, as architects and developers, it’s up to us to inform stakeholders about the impacts of their choices, offer compromises where we can, and implement in smart and responsible ways.

So, picking up on our last post, most everything about the way Drupal handles CSS holds true for JavaScript, with a few notable exceptions.

CSS aggregation removes whitespace, but JavaScript aggregation done using Drupal core's aggregation system doesn't do that or any other form of minification or uglification. It simply concatenates our scripts.

Like CSS, JavaScript also has three groups:

  • Library - Libraries, via drupal_add_library
  • Default - Modules
  • Themes - Your theme

Drupal creates aggregates for each of these three groups in the head, but can also deploy to the footer when the scope is set to ‘footer.’

When and where to load your JS

Drupal_add_js features a great option in the options array called scope that allows us to load JavaScript in the footer. This helps decrease our visual page load times by moving render-blocking JavaScript out of the way to a place where it won't impede the loading of other assets (like images, styles, other scripts).

The options array also provides an option called type which defaults to ‘file.’ When using the default option of ‘file,’ it tells Drupal that this is a script hosted on our site, so it's eligible to be aggregated. Combined with the every_page flag set to ‘true,’ just like with our CSS, these scripts get aggregated with the scripts added using ‘.info’ files into the big site-wide aggregates. If the every_page option is left out, or it is set to ‘false,’ then these scripts are aggregated as one-offs outside of our main three site-wide JavaScript aggregate files, again, just like with our CSS.

The type option can also be used to create inline scripts, which can be handy in a couple of ways. It will print our JavaScript directly into our header or footer depending on scope, but it's also useful for dynamically loading external scripts so they become asynchronous. Going forward, the async_js module is probably the way to go. I personally haven't had the opportunity to try it out, but I look forward to the chance. If you've used it, let us know in the comments how it worked out for you.

The third 'type' is the one we use for loading external scripts, which we seem to do often these days. Using an asynchronous method, mentioned above, is important because of the additional round-trip time to get the script. However, a slightly less effective way to handle it without using the older method of an inline script, or an additional module, is simply scoping the script to the footer and setting the type option to external (which prevents it from being aggregated).

Unlike with CSS, I'm less inclined to add JavaScript on every page because I like to scope JavaScript to the footer whenever possible. Since it isn't blocking render down there, the additional HTTP request doesn't really bother me. Generally, if it's on most pages, or a page visited by most users, go ahead and add it to every page. If it isn't and it's scoped to the footer, then only add it when it is needed. If it has to be in the header, and on an obscure page that isn't frequently visited by users, you're probably going to need to do some A/B testing to compare the performance hit on the obscure page by not including it on all pages vs. the performance hit on all the other pages by including it on all pages. I like to err on the side of the majority, meaning, I tend to only include the JavaScript on the obscure pages.

JavaScript: Know when to say when

You can do almost anything with JavaScript, and leveraging a framework like jQuery makes it easier to want to do everything with JavaScript. However, in addition to blocking page render and increasing the size of the page that has to be processed by the browser, there are other performance considerations with JavaScript.

It runs locally, in the browser, which means it uses a visitor's memory and processor. Poorly written or heavy use of JavaScript can lead to a poor user experience in the form of everything from delayed and choppy animations to browsers becoming unresponsive and/or crashing. For simple animations, consider using CSS3 animations, benchmark them using a tool like Chrome's dev tools or Firebug, and go with the least expensive performance option (these usually end up being the smoothest animations as well).

These script performance problems are often magnified on mobile devices where the hardware resources are more scarce and we often resort to using more JavaScript to solve challenges presented by the smaller viewport. This should reinforce the importance of a mobile first strategy, not only for design but also for development. It also highlights the need for open communication between the product owners, the design team, and the development team.

Conclusion

Scripts, like styles, contribute front-end implementations that can seriously hamper Drupal’s back-end magic. By favoring stylesheet aggregation and reigning in exuberant preprocessing, we can save the browser a lot of work. Applying the same principles to JavaScript, while properly placing scripts in the header or footer-based on function, can also improve our page-load times.

Next time, in our final post of the series, we’ll take a grab-bag look at some subtle, more specialized techniques that just might shave off those last few milliseconds. Stay tuned for a post covering Content Delivery Networks (CDN), semantic HTML, and how to encourage improved client-side content selection.

Tags:  acquia drupal planet
Catégories: Elsewhere

Acquia: Quick Tips for Writing Object Oriented Code in PHP

jeu, 09/07/2015 - 21:15

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

PSR-4 Autoloading: How to set up your files to be loaded

First things first, how do you include OO code in your project? In D7 you had to add the files to a .info file for a module or do module_load_include. In D8 all you have to do is follow PSR-4 namespacing. If you follow the PSR-4 folder and namespace structure your classes will be auto-detected. No more need to add them to a .info file! If you are writing code for D8 then it’s done. Great. In D7 you can use the XAutoload module to get PSR-4 autoloading in D7 today!

Namespacing In PHP: Loading your files

Namespacing in PHP can be confusing and misleading. In Java or .NET, in a file you first import other namespaces you intend to use. In the example below we use the “using” keyword. Then you declare the namespace wrapper for the code that is being implemented.

using System;
using Microsoft.VisualBasic.Devices;
namespace SampleNamespace
{
    class SampleClass
    {
    }
}
PHP is VERY different. It’s actually the opposite. First you declare the namespace then inside the namespace you have your “includes.” In PHP including the use statements outside of the namespace would contaminate the global-scope.

namespace SampleNamespace
use GuzzleHttp;
use GuzzleHttp\Subscriber;

class SampleClass
{
}
Now this is where things get tricky. If there is a class called Client inside GuzzleHttp then you would expect that you could use it by writing the following.

namespace SampleNamespace
use GuzzleHttp;

class SampleClass {
function sampleFunction(){
          $myClient  = new Client();
      }
}
And you would be wrong. The way that PHP interprets classes are RELATIVE to the current file’s namespace. So it actually sees “$myClient = new Client();” as “ $myClient = new SampleNamespace\Client();” which does not exist so the declaration fails. To work around this you can reference the actual class in the use statement. If you have multiple classes you must have an include for each one. It’s more verbose than what you might expect coming from .Net or Java e.g.:

namespace SampleNamespace
use GuzzleHttp\Client;
use GuzzleHttp\Subscriber\Mock;

class SampleClass {
function sampleFunction(){
          $myClient  = new Client();
   $mock = new Mock();
      }
} Dynamic Typing: A variable can be anything!

PHP is a dynamically typed language. It provides great flexibility and velocity when coding, especially procedural code. However, this can be a nightmare when you are writing OO code. It means that you cannot make assumptions about the type being passed into an object. If you make assumptions and those assumptions are invalid your code can behave unpredictably. What are you to do?

Type Hint ALL THE THINGS:

You might be surprised to know that PHP allows you to apply and enforce function param types. PHP 5 introduced the concept of type hinting. With type hinting you can set type on objects. e.g
function sampleFunction(MySampleClass $a){

If a type hint is violated, an InvalidArgumentException is thrown. There is a catch to type-hinting in PHP, it doesn’t work for scalar types e.g (string, int, bool). There is also no type hinting on return types. You’ll have to wait for PHP 7 for both. In order to work around the scalar limitation in PHP5 you’ll need to write your own functions.

Setting up your code for an IDE

One of the advantages to writing Object Oriented code is that it works really nicely with an IDE like PHPStorm. If you have written type hinted code PHPStorm will pick up on it and help you with auto completion as you work. For the things that aren’t explicitly hinted you can use PHPDoc comments. e.g

/**
* Gets a specific setting by its name/ID.
*
* @param string $id
*   The name/ID of the setting to retrieve.
*
* @return ZoneSettingBase
*   The setting object given the ID passed in.
*/
public function getSettingById($id) {
return $this->settings[$id];
}
PHPDoc comments are actually mandatory as part of drupal-coding standards. Their omission causes coder’s code sniffer to fail.

You can also type-hint variables:

/* @var GuzzleHttp\Client $client/*
private $client;
While these hints are comments and not syntax they make the developer experience a lot more pleasant. No Enums :(

PHP still doesn’t have a formal enumeration type so you will have to get creative and roll your own.

I often create CONST arrays and throw an exception if a function param is not in that array. It’s a poor-man’s enum. There is currently a proposal to add enums to PHP7. We’ll see if it makes the cut!

Associative Arrays

Associative arrays reflect the dynamic typed heritage of PHP. They are incredibly flexible and a quick and easy way to move data from one point of your app to another that being said the lack of structure requires a developer to know everything about the underlying implementation of the array. Also without a debugger they have no way to determine what is actually in an array. The dynamic nature of these arrays makes them undocumentable. That makes coding with someone else’s array hard. The idea of OO is that you have structured data and layers of abstraction so that a dev doesn’t need to know the low-level implementation details. When going OO you should try to convert arrays into structured, documentable classes that hide the underlying implementation. If you need to accept an array as input parse it and break it out into objects as soon as possible. Developers will praise you for it!

No Function Overloading

PHP does not natively support function overloading. Since PHP is dynamic it’s possible to come up with some Frankenstein solutions to get around this. However, Frankenstein code often confuses other developers interacting with your code and is to be avoided. For better or worse you need to accept this constraint.

Dusting off the design cobwebs. How to assign responsibility to classes.

The lack of overloading can actually be beneficial especially in the context of class constructors. Like normal functions you cannot have multiple constructors in PHP (You can technically write a static class method to work around this constraint). This sounds like a pain. However, it forces you to articulate the single responsibility of a class. Often overloaded class constructors can be a sign that a class is taking on too many responsibilities. For example if you have a constructor that take params and another for parsing an array you might ask why should my class know about another representation. Maybe it's a break in tiered architecture and violating a separation of responsibilities. In this case something that might be perceived as a limitation is actually supportive and liberating.

Go Forth and Write OO Code

As we transition into D8 writing solid PHP OO code is more important than ever. D8 is built around OO classes. Even in Drupal 7 we can start to strive towards an OO world. Obviously in Drupal 7 most problems don’t lend themselves to an OO approach. However, even having that option gives you new tools to solve problems in Drupal! The resulting code has a clarity and aesthetic that most procedural code just can’t match.

Finding those opportunities to apply an OO solution keeps you sharp and ready to hit the ground running on Drupal 8.

Tags:  acquia drupal planet
Catégories: Elsewhere

Cruiskeen Consulting: Drupal 8 and hosting requirements

jeu, 09/07/2015 - 19:05

I'm writing a little bit today about some of the concerns that folks are having about Drupal 8, the new hosting requirements it imposes, and particularly the concerns that smaller organizations will not be able to find Drupal 8 compatible hosting plans. There is a lot going on with us and with other hosting companies at the moment to support Drupal 8 and other PHP software that has more modern requirements. We don't think this will be an issue with most reliable hosting companies by the time Drupal 8 ships.

Catégories: Elsewhere

Acquia: Sustainable contribution 2/2 - Giving back is the same as making money.

jeu, 09/07/2015 - 18:35
Language Undefined

Part 2 of 2 - I spoke with John Faber, Managing Partner with Chapter Three, on March 17th, 2015.

In part 1 to talk about the business advantages of contribution and sustainability when basing your business on open source software. We also touch on Drupal 8's potential power as a toolset and for attracting new developers, doing business in an open source context, and more!

Catégories: Elsewhere

Drupal Bits at Web-Dev: Drush sql-query output

jeu, 09/07/2015 - 16:47

Despite several tries, I have never had any luck using the native sql output formatting commands to work with drush

Catégories: Elsewhere

Drupalize.Me: Learning Drupal 8 from Boilerplate Code

jeu, 09/07/2015 - 15:02
Drupal 8 represents a lot of changes and a steep learning curve for many Drupal developers and themers. While many of these changes are exciting, there are many things to learn just to get started. One way to learn about the code involved with Drupal 8 modules and themes is to take a look at core's modules and themes for examples to follow. Another, is to use a code scaffolding tool like Drupal Console to generate boilerplate code and comments that you learn from and then customize.
Catégories: Elsewhere

Drupal core announcements: Drupal 8's minimum PHP version increased to 5.5.9

jeu, 09/07/2015 - 06:17

Pursuant to the discussion at [policy] Require PHP 5.5, the minimum PHP version of Drupal 8 has been raised to 5.5.9, and this change will be included in the next Drupal 8 beta (8.0.0-beta13).

(PHP 5.5.9 was chosen because it is also the same minimum version as Ubuntu's LTS, which in turn influenced Symfony 3.0, Travis CI, etc.)

This is a future-proofing move which buys us a few things:

  • Some nice language features and a built-in opcode cache.
  • Compatibility with the latest versions of various external dependencies, including Guzzle 6 and the upcoming Symfony 3.0
  • Better security for our end users, since PHP 5.4 will become end of life September 15, 2015 (most likely prior to Drupal 8's release).

We looked extensively into the adoption and hosting support of PHP 5.5 prior to making this move. While there is not widespread adoption of PHP 5.5 as of today, we nevertheless found that most hosts offer the option for PHP 5.5, due to PHP's security policy.

Catégories: Elsewhere

Pages