Long story short, we had a site that wanted to change domains for marketing reasons. Simple! I said -- we just change the base_url. So then came the issue of files on the site used the old domain for storage so I went to do a find and replace. Then came the issue of all of the URLs still pointed to the old site because the content editors didn't use domain-relative URLs.
I had SUCH a great time, met lots of community members, attended sessions & BOFs, and am still trying to catch up on all the videos from the sessions that were overpacked. I was able to go with my right hand man at K&M and show him off to his first Con. While I was there I also transitioned out of my old position at Klunk & Millan and was able to onboard with my new teammates at Lehigh University.
I've got a site in my hands now that was setup without locale module and without languages. The client would now like to add translations into their site with the focus being on localizing content for the different languages. After the initial setup (locale module, entity translation, translation management w/ File import/export) I was ready to get an export of the content ready and that's when I ran into a problem.
I had a great time out at Drupaldelphia this past Friday. I met quite a few people, saw an amazing keynote by Bob Moul. To add to it all I sat in on a session about TWIG for Drupal 8, two sessions about decoupled Drupal / RESTful / API-driven content. The other sessions were focused on user experience, especially on the Content Editor side of things.
I've been running into an issue with my initial site builds where the admin menu is all out of whack. What I mean by this is that it seems to not get the parent menu link relationship correctly so the Add Views link displays directly under structure. The issue happens when I enable a ton of modules at the same time.
In Drupal setting up permissions has always been a fun part of setting up sites. You know what I'm talking about if you've experienced this pointer finger pain at least once before. For our Internal administrator role we typically need to do a permission reset to ensure that they have all of the permissions needed on the site. Rather than spending some time clicking I figured I'd spend the same amount writing a quick drush one-liner that will take care of just what is needed. The next time this needs to be done it will be a quick process.
I'm a little late to post but 2016 is off to a great start. My parents spent some time with us at the end of the year and Nikki's daughter Brooke has been visiting as well. I've decided that I'm going to get certified as a Drupal developer during the first quarter of this year so that I can take my professional adventure to the next level. I've also decided that I want to learn a lot more about cars and start doing some more work on my own.
During my work at Klunk & Millan Advertising I've built a lot of sites for clients with differing levels of administration and client involvement in their sites. All too often we want to limit the permissions of the roles so that 1.) the site is easy to use and 2.) nobody makes any unintended changes. One of my major beefs with Drupal is that we want our clients to have access to create users, but in doing so they also inherit the permission to change all of the permission levels on the site.
On my quest to set up a dev environment for our developers I've been actively working on a custom script wrapper around DrupalVM. Today I was working from home and ran into a bit of an issue when I went to run my bash script. I made some heavy usage of `sed` to modify the files to our needs and was a bit confused when my commands wouldn't work in linux. It turns out that I had been using some commands that weren't exactly portable. Lesson learned: use POSIX compliant commands only.
Recently we launched a new site for a client that uses Access Control to give users access to edit specific pages. After giving access to update a page to a single user with only the authenticated user role, the user was able to see a new tab on the node page titled Edit. After clicking Edit they were brought to the node edit form where the body was greyed out with text that read "This field has been disabled because you do not have sufficient permissions to edit it."