<![CDATA[Yanniboi's Drupal Pit]]>http://blog.yanniboi.com/Ghost 0.7Fri, 08 Dec 2017 10:15:08 GMT60<![CDATA[xDebug Config]]>I often forget my xdebug config when moving to a new machine, so here it is:

]]>
http://blog.yanniboi.com/xdebug-config/919d9a27-c94f-4561-a37f-16e24c7477cdWed, 21 Jan 2015 09:54:01 GMTI often forget my xdebug config when moving to a new machine, so here it is:

]]>
<![CDATA[My First Chrome Extension - TwitterGram]]> TwitterGram

I get annoyed frequently at how Instagram decided to deprecate Twitter Cards. This is the reason that when you share an Instagram post on Twitter, all you get is a link but no image in the tweet, and when you are scolling through your feed you have to click through

]]>
http://blog.yanniboi.com/my-first-chrome-extension-twittergram/c8c3e305-7144-4e9a-acc5-f5d70c6b1badSun, 21 Dec 2014 23:52:51 GMT TwitterGram

I get annoyed frequently at how Instagram decided to deprecate Twitter Cards. This is the reason that when you share an Instagram post on Twitter, all you get is a link but no image in the tweet, and when you are scolling through your feed you have to click through to Instagram to see what people are on about.

There are ways to fix this for your own Instagram posts. Primarily through web automation like IFTTT (more here) or other Apps, but this doesn't solve the issue that I have:

I can't see other people's Instagram posts on my Twitter feed...

So I thought this is a good a chance as any to build my first Chrome Extension. I recently got myself a Chromebook (a lot of fun!) and was eager to see how I could make this operating system work for me, not being able to customize it in my usuall fasion.

The "finished" code can be seen on my github.

Choose your weapons

Seeing as twitter already uses jQuery I thought it would be easiest to just use that for simple DOM querying and manipulating. I was also going to have to make some API requests to Instagram in order to get hold of the image URLs. Luckily I already have a few Instagram Applications and Authentication tokens from previous exploits so I didn't set up a new Application, however if I end up publishing this extension, I may well need to.

Basic Extension Structure

Now a basic Chrome Extension consists of a manifest.json file, which is the configuration file that tells Chrome exactly what the extension does and what files to load when, and a bunch of html, javascript and image files.

There are 2 basic ways of structuring a User Interface: Page Actions and Browser Actions.

Choose a browser action when the extension is relevant to most pages. Choose a page action when the extension's icon should appear or disappear, depending on the page.

Quoted from Google Documentation Overview

You can also use Content Scripts to interact with the actual web page's markup.

So I settled for a content script to scan the feed for instagram posts and add in the images, as well as a page action to show me that instagram images had been found (and just for funsies: scroll through the page to the individual posts).

The content script and the page action would send each other messages (using the Chrome Runtime Messaging service) to update each other and trigger actions, as their operational logic is otherwise completely separate.

For more detail, look at the code, or ask questions in the comments.

Final Result

Fiddle here, tweak there, google, google, google. And the final result looks pretty good, if I do (and I do) say so myself...

Before

Twitter Before Links, nothing but links...

After

Twitter After Pictures everywhere!

Want to give it a try?

Get hold of an authentication token, you will need it to make instagram requests. If you are used to this sort of thing, just create an Instagram Application and get a token yourself, otherwise click here and sign in... (Do you trust me ;$ )

Clone my git repository, put your token in the content_script.js file and load the whole directory into Chrome:

Enable Extension

  1. In Chrome, go to "chrome://extensions/".
  2. Make sure "Developer Mode" is checked in the top right corner.
  3. Click on "Load unpacked extension..." and select the twittergram directory.

Hey presto!

Thanks to @kelanidrums, for the use of his Twitter and Instagram accounts in the making of this Extension.

]]>
<![CDATA[Preparation for Ionic Apps on Mac]]>This is a 'Work in Progress' because I am neither a Mac person nor an App Developer.

So if you need expert advice, keep googling :)

Xcode

Firstly you need to install Xcode to get a default ios environment set up.
Install Xcode from the app store and register your Developer

]]>
http://blog.yanniboi.com/ionic-apps-on-mac/5fccc912-861e-42ec-af5e-9b0e81cecd0cMon, 09 Jun 2014 11:00:00 GMTThis is a 'Work in Progress' because I am neither a Mac person nor an App Developer.

So if you need expert advice, keep googling :)

Xcode

Firstly you need to install Xcode to get a default ios environment set up.
Install Xcode from the app store and register your Developer Account (btw... you need a Developer Account) and download the CLI:

Xcode -> Preferences -> Downloads -> Command Line Tools

Picture of Xcode

Node.js

We will need node installed so we can get all our dependencies. On Mac the easiest way to get Node.js is using Brewdog.

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

Next we use brewdog to install node.

brew install node

And done!

Start downloading the node modules we need to start with we will get cordova, ionic and gulp.

# FYI: -g is for global
npm install -g cordova ionic gulp

Note: You may need need to use sudo...

Building your Project

Either create a new project using the ionic command line or clone a git repo to get your project structure:

# New Project
ionic start myApp sidemenu

# Use Existing
git clone --branch ionic https://github.com/yanniboi/ss_bible.git

Change into the project root directory and build your project:

ionic platform add ios    # Add the ios platform to project
ionic build ios           # Compile the ios code
ionic emulate ios         # Launch the app on an ios Simulator

ionic run ios             # Launch on device*

*Once you have your device registered and the app signed.

iOS Device Signing

So up to now you have an Ionic app that you can run on an iOS Simulator, but not on an actual device. This is really as far as I've gotten myself, I don't own ANY Apple products.

I have done the above work on a virtual machine using iAtkos

But in theory people are able to get Developer Certificate, App Certificate, Device Certificate and tie them all together to allow you to test a single App on a couple of devices...

Good luck!

Getting Started with Ionic

Homebrew

Install Node.js on Mac

iOS Dev Centre

]]>
<![CDATA[Programmatically create a Commerce File License]]>Sometimes you want to license files without people needing to purchase them. Even using coupon codes to make products free still requires them to be purchased through the Commerce Checkout system.

This is fine for physical products where you still want email and address details of potential future clients.

However

]]>
http://blog.yanniboi.com/create-file-license/c124fdcd-437a-4c3e-bb0d-40f35c201ab7Mon, 28 Apr 2014 11:00:00 GMTSometimes you want to license files without people needing to purchase them. Even using coupon codes to make products free still requires them to be purchased through the Commerce Checkout system.

This is fine for physical products where you still want email and address details of potential future clients.

However when it comes to files, users require an account to access their files, so chances are you have all the details for them already. And there is no shipping required so why make them go through the checkout process just to get a license for a free file? (Seriously if you have reasons comment!)

Here is a snippet of how to generate a file license for a user:


Unrelated

Grammar Lesson:

Today I learnt the difference between 'license' and 'licence'. Unless you are American (in which case just ignore the existence of 'licence') read this.

]]>
<![CDATA[Delete Database all the things...]]>

Super Site Deployment with ctools exportable revert snippets

Sometimes when you are deploying new code to a production site you want to update views, panels, etc. with new code exports, but for one reason or another the defaults are overriden by the database.

Well with the following scripts you can

]]>
http://blog.yanniboi.com/delete-database-all-the-things/2d80a7e3-7d37-4c17-86e2-c97b71888250Tue, 15 Apr 2014 11:00:00 GMT

Super Site Deployment with ctools exportable revert snippets

Sometimes when you are deploying new code to a production site you want to update views, panels, etc. with new code exports, but for one reason or another the defaults are overriden by the database.

Well with the following scripts you can stop worrying about that and just have an update hook take care of reverting (or deleting) the overriding database entries.

Improvements appreciated and feel free to comment!

]]>
<![CDATA[Super Environment - Drush Aliases]]>Alias Directory

You can place the aliases.drushrc file either in the 'sites/all/drush' directory or your global environment drush folder (eg. /home/username/.drush) and the naming convention is 'group.aliases.drushrc.php' so I normally use 'project.aliases.drushrc.php' or 'client.aliases.drushrc.

]]>
http://blog.yanniboi.com/super-environment-drush-aliases/04d6f93d-4dc5-4e67-8bf6-5661f8baad78Mon, 14 Apr 2014 11:00:00 GMTAlias Directory

You can place the aliases.drushrc file either in the 'sites/all/drush' directory or your global environment drush folder (eg. /home/username/.drush) and the naming convention is 'group.aliases.drushrc.php' so I normally use 'project.aliases.drushrc.php' or 'client.aliases.drushrc.php' to group related sites.

Dev (/local)

Create an alias array defining your local development site:

$aliases['dev'] = array(
  'uri' => 'sitename.dev',      // The uri as configured in you apache hosts
  'root' => '/path/to/web/root',
  'path-aliases' => array(
    '%files' => 'sites/default/files',
   ),
);

You can now (if you placed the alias file in your global drush directory) use drush from any directory, using:

drush @project.dev status

or

drush @project.dev cc all

Did you say any directory?!

Yep! Since you have defined you webroot in the global drush aliases file, you don't have to be in your webroot when running drush, and really, you don't even have to be on the same server...

Production (/remote)

To get the alias details for a remote machine, the easiest place to start would be to just ssh into it and run:

drush sa @self --with-db --show-passwords --with-optional

The result looks like this:

$aliases['self'] = array (
  'root' => '/path/to/drupal/root',
  'uri' => 'http://default',
  'path-aliases' => array(
    '%drush' => '/path/to/drush',
    '%site' => 'sites/default/', 
  ),
  'databases' => array(
    'default' => array(
      'default' => array(
        'database' => 'site_db',
        'username' => 'site_user',
        'password' => 'site_pass',
        'host' => 'localhost',
        'port' => '',
        'driver' => 'mysql',
        'prefix' => '',
      ),
    ),
  ),
);

You can just copy this directly into your local drush alias file and add remote details liek this:

$aliases['live'] = array (
...
  'uri' => 'http://mysite.com',
  'remote-host' => 'ip.or.domain',
  'remote-user' => 'ssh_user',
...
  'path-aliases' => array(
    '%files' => 'sites/default/files',
...

The result allows you to run drush commands locally and have them acting on a remote site.

Jiminy Cricket!

Optional extras:

  'remote-port' => 3201,

If you have a seperate port for mysql

  'ssh-options' => '-o PasswordAuthentication=yes',

If you can't use an ssh key

Syncing files

You can sync the files directory between sites:

drush rsync -y @project.live:%files @project.dev:sites/default

or

drush -r /path/to/web/root rsync -y @project.live:%files @self:sites/default

This post is mainly snippets and tips for me to remember drushrc tools in my day to day work.
Other (/better) blog posts are as follows:

]]>
<![CDATA[How to install and configure Solr for Drupal]]>

Disclaimer: I have much more experience USING Solr with Drupal than setting up a Solr service so please use the comments to correct me.

Having Solr index your content has loads of benefits, but best of all in my humble opinion is the beauty of have facetted filtered search. Of

]]>
http://blog.yanniboi.com/solr-for-drupal/e7c37cd0-e885-4475-96e1-6e6841d50009Fri, 01 Nov 2013 12:00:00 GMT

Disclaimer: I have much more experience USING Solr with Drupal than setting up a Solr service so please use the comments to correct me.

Having Solr index your content has loads of benefits, but best of all in my humble opinion is the beauty of have facetted filtered search. Of course you could do it with database indexes, but the performance win of using Solr is very noticeable.

Prerequisites:

  • A working LAMP stack.
    • I am using Ubuntu 12.04.
  • Java version 1.6 or higher.
    • Use 'java -version' to check.

Download Solr

Download a copy of the Solr tarball to your computer and extract it to a directory of your choice. Make sure you have root privileges, otherwise you will need to prepend 'sudo' to the following:

cd /usr/share
wget http://mirrors.ukfast.co.uk/sites/ftp.apache.org/lucene/solr/4.5.1/solr-4.5.1.tgz
tar zxvf solr-4.5.1.tgz
rm solr-4.5.1.tgz
mv solr-4.5.1 solr

And now you have Solr downloaded. You can test it by going to the example directory and executing the start.jar

cd /usr/share/solr/example
sudo java -jar start.jar

Now if you navigate to the example.com:8983/solr you should get this lovely screen:

Now it is a bit of hassle always having to run a command from terminal when you want to start solr so here is a little trick to automate it.

cd /etc/init
vim start-solr.conf

Enter the following into the file and save it.

# start-solr

start on startup

script
    cd /usr/share/solr/example
    java -jar start.jar
end script

Now solr will start whenever the machine you are running starts up.

Configure Solr for Drupal

Most of what you need to know for this can be found on d.o here but I will take you through it anyway.

Download the newest release of the Drupal search_api_solr module. There are some files that we need to to our solr settings.

cd /path/to/search_api_solr/solr-conf
cp 4.x/*  /usr/share/solr/example/solr/collection1/conf/

And that is pretty much it. Simples!

Configure Drupal for Solr

Now install Drupal and Search API Solr (including dependencies) as you would normally. Go to the Search API configuration page (example.com/admin/config/search/search_api) add a new server (choosing Solr as the service class) and if you get this wonderful message:

you are done!

You can now index Drupal to your heart's delight.

]]>
<![CDATA[There's a Partyopoly in Drupal and you're invited...]]>So, Partyopoly is in alpha2 and I thought it was time to start talking about it. There is a long and well thought out description on the sandbox page, but it's a bit marketing-y and I am more of a fan of look and touch than lets think about it.

]]>
http://blog.yanniboi.com/partyopoly-intro/2f2bc11c-57bd-4c8f-92f3-3158b9052177Wed, 30 Oct 2013 12:00:00 GMTSo, Partyopoly is in alpha2 and I thought it was time to start talking about it. There is a long and well thought out description on the sandbox page, but it's a bit marketing-y and I am more of a fan of look and touch than lets think about it.

So here it is!

The Journey

I have been working on this project for a long time on many different sites and iterations, but I wanted to figure out how the 'package' as it currently exits works for someone who has never used it before...

Installing

Partyopoly is currently still in a sandbox. So the best way to get it on a server is to git clone the repository and then use 'drush make' to build it the web root.

cd /var/www/git

git clone http://git.drupal.org/sandbox/rlmumford/1905260.git partyopoly

drush make partyopoly/build-partyopoly.make /var/www/partyopoly

This will build drupal and download a huge amount of modules that partyopoly requires, while checking out the relative commit messages and in some cases applying various patches from the various issue queues.

Don't you love distributed code?

Now you are able to install drupal as usuall and... Oh dear, it uses omega as a default theme!

Quick, throw Marinelli on there so that it at least has some skin!

Anyone else struggle to find simple clean drupal themes for demo sites?

Now we need to configure it a little.

Configuration

First things first, Partyopoly has a wonderful feature that is the Party Dashboard, but before we can take a closer look, we need to configure solr.

< shock > No not SOLR! < / shock >

Don't worry, you can swap out the Solr Server with a Database Server and the indexes will still work out of the box.

If you have never set up solr before these two posts should help:

Or you could read my blog post (shameless plug) here

Next head over to

Configuration -> Search and Metadata -> Search API 

(/admin/config/search/search_api) and enable the Solr Server and the Party Index

Next we can start adding Parties to the site. Go to the Party Dashboard (/admin/party). This should still be a bit boring because our index is empty,

so click on Add Individual, fill in some details and save.

We may need to clear caches or go back to the Party Index settings and tell it to index the first time, but we should now have our first Party on the Dashboard!

Boom!

Lets start building!

Lets add a few more Individuals and also an Organisation. Its starting to look pretty good.

I can even add Individuals to said Organisation or kill off an employee!

Imaginary employee homocide is no joke, so lets not get carried away!

That is basically it! There are many more things that Partyopoly comes with, but as a first taste, I think that suffices.

Demo Site:

Feel free to click around the demo site to have a look, but don't try to add/edit/delete any content...

]]>
<![CDATA[Drupal 8 Module Port - Theming and Twig]]>

This is Part 5 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

Theming

]]>
http://blog.yanniboi.com/drupal-8-module-port-theming-and-twig/e16bd2f8-6915-4212-bd07-4e18d5e9a6f0Tue, 20 Aug 2013 11:00:00 GMT

This is Part 5 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

Theming content in Drupal 8 is very different to Drupal 7. For more in depth information about which problems were solved and why, have a look at this great presentation (http://www.youtube.com/watch?v=adrW67KrdUY) by Jen Lampton at an East Bay Drupal Users group meetup.

In Drupal 8 Twig is a great format to work with, amoung other reasons, because it is readable, intuitive and automatically sanitised.

Hurray for closing security holes!

Show me code!

I will be looking at how to much from a theme function in Drupal 7 to a twig file in Drupal 8.

In Drupal 7, you could have a render array with a #theme key, a theme hook to map a theme key to a theme function, and said theme function. On top of this, you could have preprocess functions, template files, pre-render, post-render, and a huge mess of code.

Drupal 8 doesn't change EVERYTHING. We still have render arrays and hook_theme, and even preprocess functions to modify and clean up our variables. But the big difference is that we pass those variables to a *.html.twig template file

Important Notes

You can immediately notice how much easier it is to see what is going on. To use any of your theme variables, just pop them in {{}}'s and twig will work out whether to print/render/print render it. As I stated above, twig takes care of sanitizing code and knows if the code came from the database or user input. The {% spaceless %} tag even strips out whitespace for you, and you/the themer can focus on what is important. Beautiful themes!

]]>
<![CDATA[Drupal 8 Module Port - Blocks and the Plugin API]]>

This is Part 4 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

This

]]>
http://blog.yanniboi.com/drupal-8-module-port-blocks-and-the-plugin-api/147a2823-a067-4982-bd51-1fbd532af7e1Sun, 18 Aug 2013 11:00:00 GMT

This is Part 4 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

This time we are going to dig deep into Drupal 8, and have a look at the new Plugin API. With ctools in core it was about time to re-examine blocks for Drupal 8. Blocks are now Plugins (as are views, entities and virtually everything else..), but what does that mean practically?

We no longer use hook_block_info, hook_block_view, hook_block_allthethings, etc. to store blocks in code, we simply extend the BlockBase class in:

'lib/Drupal/MYMODULE/Plugin/Block/CLASSNAME.php'.

(If this seems weird, see the previous post about forms)

Show me code!

This is what my class in InstagramBlockBlock.php looks like:

This looks a bit daunting at first, but all you really need is build() to build the render array and (VERY IMPORTANT) the plugin definition in the class docblock.

Important Notes

"What I put in the comment matters?!", I hear you asking... Yes it does! In Drupal 8 we implement Doctrine's Annotation system which means most classes need to have Annotations to register the plugins they are defining. In other words, if your class commenting is wrong, your block will not be found by Drupal.

For our block we need the id and admin_label.

And boom, we have a block!

Now of course we don't just want a block that is hardcoded, we want a configurable block. So we need to implement blockForm() and blockSubmit(), which allow us to put a form on the block edit page without having to use hook_block_configure() and hook_block_save().

Once you have defined your block in code, you can go to admin/structure/block page and 'place' the block in the theme using the UI on the right side of that page.

]]>
<![CDATA[Drupal 8 Module Port - Forms]]>

This is Part 3 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

Now

]]>
http://blog.yanniboi.com/drupal-8-module-port-forms/735601af-d503-4923-8c1c-93e06a83a15fSat, 17 Aug 2013 11:00:00 GMT

This is Part 3 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

Now we are going to have a look at getting a form on a page. You may have noticed this line in the last post when we created a configuration page:

  pattern: '/admin/config/content/instagram_block'
  defaults:
    _form: 'Drupal\instagram_block\Form\InstagramBlockForm'

Rather than telling Drupal to create a page and then render a form on that page, we are telling the routing system straight away that at that url we will be putting a form.

Now lets have a look at OOP. Because Drupal 8 doesn't require all classes to have unique names, we need to make sure any classes we define are not only located in the correct folders, but also have the correct 'namespaces'.

For example, the correct place to put a class that creates a form in Drupal 8 is

'MODULEFOLDER/lib/Drupal/MODULENAME/Form/CLASSNAME.php'.

In our case, as above the correct place is

'instagram_block/lib/Drupal/instagram_block/Form/InstagramBlockForm.php'

This may look very strange, but this will make perfect sense later.

Show me code!

Now lets have a look at the code and then go through it piece by piece:

Important Notes

Class definition

Now the top of the file is used mainly for telling Drupal about this class and making sure it can find it if needed. Drupal finds this class by combining the class name, InstagramBlockForm, and the namespace, Drupal\instagram_block\Form, which as it turns out is also the directory we are in. It isn't so much of a problem with this particular class, because it is unlikely that another class has the same name, but if there were another implementation of the same class name elsewhere, then in the top of the class implementing our form object there would be a line:

use Drupal\instagram_block\Form\InstagramBlockForm;

This translates as 'Whenever the following class uses the InstagramBlockForm class, look for that class in the Drupal\instagram_block\Form directory'.

In our form we also have a 'use' statement, 'use Drupal\Core\Form\ConfigFormBase'. This means that in our class definition 'class InstagramBlockForm extends ConfigFormBase', we are referring to the Drupal\Core\Form\ConfigFormBase class.

Form build and submit

Now the rest is quite straight forward. We set a unique form_id using getFormID(), we build out renderable form array in buildFrom() and we submit our form in submitForm(). We could also have implemented validateForm(), but we aren't going to do that for this form.

The interesting stuff happens with the lines:

parent::buildForm($form, $form_state);

and

parent::submitForm($form, $form_state);

Because we have chosen to extend ConfigFormBase and not FormBase (which we would have done for a generic form), we can call the parent implementations of those two methods to some nice things like create a submit button for us, or set a confirmation message when the form is saved.

Thanks ConfigFormBase!

We will have a closer look at what is happening in the buildForm() and submitForm() methods after we have looked at blocks.

]]>
<![CDATA[Drupal 8 Module Port - Pages and Menu routing]]>

This is Part 2 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

In

]]>
http://blog.yanniboi.com/drupal-8-module-port-pages-menu-routing/ffe1d4c8-f91e-4f3e-83da-2b5fda6bdb21Fri, 16 Aug 2013 11:00:00 GMT

This is Part 2 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

In Drupal 7 we used to just implement hook_menu() and this would take care of everything to do with the menu items defined by our module, however in Drupal 8 we only need to register the menu item using hook_menu(). That is, we only need to define the menu item title, description, callback type and/or callback context. The rest is is handled by the new Symfony based Menu Routing system.

Show me code!

In practice this means, our hook_menu changes to look like this:

and we also add a *.routing.yaml file:

Important Notes

Make sure you define 'router_name' so that the router knows which menu item to extend.

Eventually the router will be able to handle all of the hook_menu() functionality and we will not have to write a seperate hook for menu items, but that is not yet the case.

]]>
<![CDATA[Drupal 8 Module Port - Module Basics]]>

This is Part 1 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

First

]]>
http://blog.yanniboi.com/drupal-8-module-port-module-basics/11b58457-5620-448f-beb2-40b1446ff592Thu, 15 Aug 2013 11:00:00 GMT

This is Part 1 of a blog series about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

First lets have a look and compare module layouts in Drupal 7 and 8:

Drupal 7 Module

Image: Drupal 7 Module Layout

Drupal 8 Module

Image: Drupal 8 Module Layout

We still have a *.module file as before, but the *.info file is now a *.info.yml file using the new drupal yml file type (https://drupal.org/node/2000204).

We also, rather than separate our extra code and class definitions into .inc files, put all of our object oriented code into the 'lib' directory.

Show me code!

Now before I go into any more detail, lets just get practical.

This is what our .info file looked like in drupal 7:

name = Instagram Block
description = Creates a block that displays images from instagram.
package = Social
core = 7.x

dependencies[] = block

And now it looks like this:

name: Instagram Block
type: module
description: 'Creates a block that displays images from instagram.'
package: Social
core: 8.x

dependencies:
  - block

configure: admin/config/content/instagram_block

Important Notes

  • ':' instead of '='
  • indenting
  • type needs to be set
    • Drupal will not find the module unless type is set, no matter which directory you put it in.
]]>
<![CDATA[Drupal 8 Module Port - Introduction]]>

This is a blog about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

I have been playing with

]]>
http://blog.yanniboi.com/drupal-8-module-port-introduction/f31478b0-3d86-4c93-8e69-5ee1682d426bWed, 14 Aug 2013 11:00:00 GMT

This is a blog about my recent experiences of porting the Instagram Block module from Drupal 7 to Drupal 8. Since Drupal 8 is still in alpha, APIs are subject to change. Also I may not be using best practises so commenting is heavily appreciated!

I have been playing with Drupal 8 for a couple of days now (what else would you do during a 2 week holiday?), and I really wanted to share what I have learned so far. So I decided to port a module that I had built previously and show every different part of the transformation to Drupal 8.

As it turns out, Instagram Block module actually quite nicely allows to demonstrate a lot of the new areas of Drupal 8, including theming with twig, annotation, symfony menu routing, and configuration management. So here are the links to the individual posts:

  1. Module Basics

  2. Pages and Menu routing

  3. Forms

  4. Blocks and the Plugin API

  5. Theming and Twig

]]>