Spokane Drupal Group December 15

jhodgdon's picture
2016-12-15 10:00 - 12:00 America/Los_Angeles
Event type: 
User group meeting

We hope you can join us for the next meeting of the Spokane Drupal User Group!

Thursday, December 15, 2016, 10 AM to noon
We meet on the 2nd or 3rd Thursday of most months at this time/location. Log in and join the Spokane Drupal User Group (see sidebar on https://groups.drupal.org/spokane-wa ) to be notified of future meetings, events, and discussions (typically just a few email messages per month).
Spokane County Library - Argonne branch, 4322 N. Argonne Road, Millwood. We are currently meeting in the small conference room at the library. From the hallway, go into the library proper, past the checkout/information desk, take a right and you'll see the room on the right.
To be reminded, sign up!
To receive an email reminder closer to the date of the meeting, log in and click the "Sign up" button; log in and click "Cancel signup" at a later time if your schedule changes and you can no longer come. There's no obligation to come if you sign up (but we hope you will!). There's also no obligation to sign up in order to come (it's up to you if you want a reminder or not). However, the meeting could be canceled if the organizer isn't sure anyone is coming.
We spend two hours in a question and answer format, with the participants around a table and a laptop on a projector. Come with questions about a project you're working on, something you've learned that you'd like to share with others, a desire to improve Drupal in some way (documentation, programming, design, marketing etc.), or a desire to help others with their projects and questions. Or just come and listen and observe.
Everyone is welcome -- the only prerequisite is having some interest in Drupal. This group is usually 5-10 friendly people, with experience levels ranging from novice to expert, so you'll fit right in. Because of the size of the group, you will have time to share something you've learned, or get your questions answered, or both!


Meeting notes

jhodgdon's picture

What we talked about today:

  • Pacific Northwest Drupal Summit: Feb 25-26, Vancouver BC
  • Jon regularly looks at his system logs in Admin > Reports > Recent log messages. He is swamped by 404 not found messages, mostly for wp-admin.php (people trying to see if it's a WordPress site) and apple-touch-icon.png and similar URLs (people trying to make links on their phones to your site -- the phone tries to find this icon to use on the phone).

    So. To fix the first, you can use the Redirect module https://www.drupal.org/project/redirect to redirect wp-admin.php to someplace (Jon suggests the FBI).

    To fix the second, you can generate an icon image, then convert it to the right file names with this tool:
    Then drop the icons in the web document root. Then check the logs and see which files are still being requested and copy those files to the required file names. Voila! Now when people make links on phones, they get a branded icons.

    Or, you could try to use the Touch Icons module (7.x only): https://www.drupal.org/project/touch_icons -- but it looks like it probably doesn't do all the necessary files.

  • Shawn and Jon said they've been conversing about the Webform module https://www.drupal.org/project/webform -- Jon is now the guru and promises to do a presentation on how he was able to set it up to do complicated logic and forms, with multiple email etc.
  • Webforms vs. Content types (as a solution for people needing to submit stuff to your site):
    - Webform has lots of modules to add functionality to forms
    - Webforms can be multi-page -- hard to do with content submissions
    - If the submission is meant to be displayed eventually as content on your site, you are better off using content items (saves having to convert it later). Set it to be unpublished by default, and an admin can approve it.
    - Out of the box, webforms send email, including multiple messages per submission. If you use content types, you can send email using the Rules module https://www.drupal.org/project/rules
    - If you use content types, you have to have complicated permissions, because content items are "meant" to be displayed as pages on your site, and you have to override that, whereas webform submissions are "meant" to be viewed by admins only, so that is already set up for you.
    - The native Views integration for Webform is lame. Jon is looking into other solutions and will report back.
    In general, you are usually better off going with a solution that has the right "mindset" for what you are trying to accomplish, rather than trying to coerce another solution into doing what you want.
  • Shawn has (long story!) come across a need to base-64 encode images. See this module: https://www.drupal.org/project/image_base64 . He also had to store text content in such a way that JavaScript could access it -- he json-encoded it and put it in a div.
  • Shawn is using the Content Access module. He wants to be able to list which roles have which permissions on a given content type. Is this possible?

    The reason is that admins need to tag content for which roles can access it, using a simple dropdown.

    To turn it around... You could use Taxonomy Access Control to define the access:
    Then the admins would just use a particular Taxonomy to define the access, and it would be relatively simple.

    Also want to have some kind of a block on a page (content item) that would display which roles have access to view the page.... let's see.

    Function user_roles() would give you a list of which roles with a certain named permission:
    But this will only work with named permissions. Using the Content Access module, you are outside the permission system that uses named permissions like "edit any article content".

    Might want to read
    which is a topic explaining the core framework for content access permissions (which the Content Access module is built on).

  • Jon put in a word for always writing down a Procedure for anything you do on a site. Otherwise your knowledge will be lost. You may need to do the same thing again, and the next time it will be faster and easier if you have a procedure written down. Jennifer loves documentation and seconds the motion.
  • Jennifer showed off the User Guide, which is now finally on Drupal.org:
    It has translations (in progress) into several languages! And it should be a good learning tool for people new to Drupal.

    You can use https://simplytest.me/ to make a temporary testing site.

  • How to combat spam user account registrations for your site:
    - Can use a Captcha to reduce them somewhat
    - The Mollom module uses a service to reduce spam https://www.drupal.org/project/mollom (like the Akismet service for WordPress)
    - If you don't need people to register for accounts, you can turn it off at Administration > Configuration > User account settings -- the section is "Who can register for accounts". Set to "Administrators only" and then no one can register for their own account.
  • Shawn wants to set up a process to get data into a site. Jennifer suggests the Feeds module: https://www.drupal.org/project/feeds