The Pro Drupal 7 Development Study Group in Los Angeles is a group that meets weekly to advance its understanding of Drupal (primarily Drupal 7) using the book Pro Drupal 7 Development by John VanDyk and Todd Tomlinson as a study guide. The format of the group is to read the book outside of the meeting and to bring questions and discussions to the group.
The group meets three Monday nights a month at Droplabs in Downtown Los Angeles. The fourth Monday night is our neighboring Drupal Meeting in Pasadena.
Our "planning" and "administration" discussion is at http://groups.drupal.org/node/154494, while this wiki http://groups.drupal.org/node/158514 provides "learning content" and clarifications of D7 materials.
The books are on loan for the duration of the study group. If you mark up your book or decide you need to keep it at the end of the study group, the cost of the book is priced face value (just under $50, no sales tax). To borrow a copy of the book, please provide Paul Chernick with your name, snail mail address, phone number and email address.
Location
Droplabs
651 Clover St.
Los Angeles, CA 90031
Droplabs is in the Mission Junction neighborhood of Los Angeles at Big Art Labs, just 1 mile down Main St. from Philippes (the first-ever venue for LA Drupal meetups!) and Union Station. We're one block west of The Brewery, the largest live-and-work artists' colony in the world. As you enter the gate off of Clover we are in the right hand corner of Big Art Labs farthest from the street.
What to bring
Just bring your copy of Pro Drupal 7 Development, laptop, your business cards or whatever else you need. We share a large parking lot with Big Art Labs and there's plenty of free parking. After you pull into the parking lot, park to the left of the entrance and follow the signs to Droplabs. Food and beverages or donations for food are very welcome!
Please note that our guest wireless network is limited to 1Mb per client, so bring your MiFi router or a phone you can tether with if for some reason you need a lot of bandwidth. Access to our high-speed network is included with a Droplabs membership.
To get last-minute updates, follow @Droplabs on Twitter at https://twitter.com/Droplabs or find us on Facebook at https://www.facebook.com/DroplabsLA
About Droplabs
Droplabs is a collaborative Drupal event and coworking space in Downtown Los Angeles. Created in 2011 by LA Drupal members for the LA Drupal community, we are focused on serving the greater LA Drupal community, enriching the Drupal skills and lives of its members, and bringing joy to our Drupal practice.
We've been open to the public since May, 2011, and the use of our equipment and facilities, including conference room, tables and chairs, is free until our official launch. See http://groups.drupal.org/node/145934 for more details about our open beta period and http://droplabs.net/prices for our list of free amenities and member perks, including our high-speed WiFi, an espresso machine, printer and scanner services, and more.
Droplabs is the host of the monthly Downtown LA Drupal meetups, LA Drupal's weekly Pro Drupal 7 Development book study group and special events including the Varnish 3 Release Party and LA Drupal's first-ever Drupal job fair. To learn more about Droplabs, follow @Droplabs on Twitter, sign up at Meetup.com/Droplabs or like DroplabsLA on Facebook!
[Temporary Note: Its a new wiki, and being the first to edit the main wiki area, I've added standalone comments to date, I've decided to wing it. Be bold. Edit my additions. Pete]
Resource Links
Based upon expressed interest at the meetings I'm posting some pages at do.org and api.do.org, where some members might find answers. Do bring the answers to the next meeting as I'm sure others what to know. Please add to the list.
-
Converting modules from 6 to 7.
http://drupal.org/update/modules/6/7
Note the side menu has links to specialized migration documentation. -
What is a hook? What functions are available?
http://api.drupal.org/api/drupal/includes--module.inc/group/hooks/7 - SimpleTest http://drupal.org/simpletest
Drupal 6 to 7 Differences
Per our discussion last night, June 18, 2011, I am starting the list in the wiki, not a comment, so everyone can edit it. Please add to the list.
- Chapter 4 - Databases - new object oriented functions and methods.
- Some function arguments are now "parameter" array keys. Need chapter and functions this is true for.
- Chapter 14 - Files - rumor of less typing, easier interface
| Attachment | Size |
|---|---|
| drupal_for_firefox.follow_the_numbers_clicking.png | 22.79 KB |
Comments
Recap of the first 2 weeks
We've had 2 great meetings of the study group.
During the first meeting we discussed logistics and organization and Peter Benjamin gave a wonderful overview of the structure of the book. During the meeting we decided to study the first 3 chapters of the book (Drupal core, writing a module, and Hooks, Events and Triggers) in the second meeting. Books were handed out during the first meeting. This wiki was discussed.
Last night in the second meeting, we discussed what Drupal provides fresh out of the box, a few differences between core Drupal 6 and core Drupal 7, module writing, especially hooks, how fields in Drupal 7 replace the CCK contribute module in Drupal 6 and entities. We briefly touched on chapter 3 Hooks, Events and Triggers and why you might want to use it. We also noted that we will not meet on the Fourth of July, and that we either will skip a meeting on July 18th or we will have that meeting in another city that does not depend on the 405 as a major artery for traffic (such as Las Vegas).
Paul Chernick
CEO
Chernick Consulting
(310) 569-2517
Review of Reviewing Chapters 1, 2 and 3
Several notes to other Study groups about what to expect when reviewing the first chapters. Expect several good off-chapter topic discussions at the "first" meeting(s) as listed below. Expectations are the group's leader will allow many minutes on these topics, but if it goes too long, then the leader should refocus talk on then next book section. Attendees eagerly jumped at this refocus.
1) The more vocal experts will establish themselves and tend to dominate the first review meeting. Be fine with that. I found the more I got these experts to speak, answer my questions, the more I learned.
2) Differences between D6 and D7 hook functions, API functions, array keys (additions), fields and entities, and the like. The experts in the group were seeking this information.
3) Topics will range over the entirety of Drupal, including theming, coding practices, finding Best Practices (or not), PHP issues such as array structure review (not all attendees will be die hard PHP coders, at ease with multi level association array structure), submitting patches, finding modules with the features you want, adding features to contrib modules, hacking core, book errata (submit it as you find it), and others.
Many group members spoke up about this pattern, and the consensus was it would only happen at the first meeting. And that once these topics were covered at the first meeting, subsequent meetings would be free of off-chapter topics.
Our meeting last Monday had about 1/3rd of it spend on off-chapter topics. We had to rush Chapter 3, Events, Triggers and Actions.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Reminder for 7/11/2011
We will be reviewing Chapter 4 at the next sessions. We will spend a brief time going over anything from chapters 2 and 3 to provide for any new comers and people that did not have the book prior to Monday June 27th.
Paul Chernick
CEO
Chernick Consulting
(310) 569-2517
Chapter Page Length Considerations for Weekly Schedule
[I added updates/corrections to chapters we have covered. They are in single brackets.]
To assist other Drupal Study groups get a grasp of the size of undertaking, here is the chapter page count analysis, that may assist dividing chapters into sets for weekly study. We found that doing a constant 3 chapters per week was not desirable. Below is why.
We decided to cover the chapters in order. Sometimes 3 medium/small chapters might be done in one meeting. Other times, either the size or importance of a chapter might mean only 1 chapter is reviewed at a meeting. We are deciding the grouping as we go. Expectations are this wiki will have weekly updates giving highlights from each meeting.
I found the Table Of Contents online at http://www.apress.com/9781430228387
See the download tab to download source code for 14 chapters' modules.
The Table Of Contents has two parts, a one page list of the Chapter Titles (used below), and a dozen pages, where topics within each chapter are listed, about 10-25 topics per chapter. Reading the latter might assist novices in greater understanding of coined terminology sooner, a key part of learning to code Drupal.
Legend: ** indicates chapters our group has determined are important, and will be the only chapter reviewed at the weekly meeting.
The four largest chapters total 186 pages of 624 pages in the book, or just under 1/3rd the book are:
34 Localization
38 Theme
56 Form API **
58 Database Ref Table App A
There are 9 medium sized chapters totaling 224 book pages.
32 Menu ** [Wildcard section was hard to understand, and needed API doc pages.]
26 Database ** [This chapter deals with custom tables, not core tables - downgrading it's importance, plus it's a short chapter, easily understood, and will not take a full meeting, maybe up to half of one.]
28 JQuery
26 Optimize
24 Hooks
22 Users
22 Fields
22 Taxonomy
22 Security
The remaining chapters are small, totaling 170 pages and their page lengths are
20 4 chapters
16 1 chapter
14 2 chapters
12 3 chapters
10 1 chapter
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Drupal For Firebug - How To Display Drupal Internal Arrays
"Drupal For Firebug" is a must have Firefox extension to greatly speeds debugging Drupal programming of core and modules. It displays the web server side Drupal internal arrays, ready for copy and paste into PHP code, in the Firebug's window pane. Two installs must be done, one each for web server and client.
https://addons.mozilla.org/en-US/firefox/addon/drupal-for-firebug/
http://drupal.org/project/drupalforfirebug
-or-
drush dl drupalforfirebug
drush enable drupalforfirebug
To try it out, visit any web page on your drupal site, turn on Firebug, click on the tab "Drupal". See the image which has this tab circled with the digit 1 displayed next to it. The Drupal sub menu bar appears below the tabs. Click on each menu, in turn, looking for when the text just below the menu turns blue, but not underline, indicating it's clickable. Click on the blue text and below it the Drupal internal array(s) will be displayed.
Easy? Once, you've been told how. The tab Drupal is not a readily obvious change in Firebug. The appearance of the sub menu can escape notice. The blue text not being underline leads a few to conclude Drupal For Firebug does not work. Thus, this post, and these steps are displayed in the below image.
"View Source" is way to confirm the web server side, the "Drupal For Firebug" Drupal module is working. At the bottom of the page is an extra DIV tag, containing all the needed Drupal for Firebug internal arrays.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Feel free to discuss and comment here!
Everyone,
We have had some awesome discussions in the study group when we meet at Droplabs. I think we can have awesome discussions online as well. I think everyone should be open to asking and answering questions here on the discussion page. Keep in mind, there are no dumb questions. If you feel you are falling behind the group, this is the best place to try and catch up!
Paul
Paul Chernick
CEO
Chernick Consulting
(310) 569-2517
July 11, 2011 Meeting Minutes
LA Drupal User Group
Book Study Group
Meeting Minutes
July 11, 2011
By Peter Benjamin
Book: Pro Drupal 7 Development, 3ed, by Todd Tomlinson and John K. VanDyk
These notes do not cover the entire meeting. Nor does it summarize the chapter material. They are more a reminder to attendees of what the answers were. Perhaps other Drupalers can find clarifications for themselves. This book study group when handling the same book might find value here. Other book study groups might use the notes to drive discussion.
Next Meeting
The last half of Chapter 4, the remaining part of Wild cards will be covered, and then Chapter 5 as well. Do read Chapter 5. If the 405 Bridge is down Monday morning, then our meeting will be on. If not, then the meeting will be canceled. Keep reading our groups.drupal.org/node/54494 and 158514.
Attendee Notes
There are 17 study group members. If all 17 show up, chairs will be a problem, as will the "round table" set up we like. Tonight, we had 12. Blake, Uzi, Stew, Ron, Paul, Lee, Christefano, Jerid, Scott, Tommy, Benno, and Pete. All chairs available, 11, were taken. Christefano sat on a Pilate ball, his preference, which strengthens the back.
Errata
Will this group find and submit errata? The Apress section for this book has no errata. The errata appears to be found at DrupalBook.com, 5 pages of it. Some of the existing errata we found, and some we found is new. I've signed in my new account there, and will add a few errata, and see how fast they show up.
We will submit errata that is technically wrong, and not worry about grammar and such. Discussion reviewed about 10 such, to determine what this level is.
We did not get to figuring out who would type it in, but typing it in at the end of each meeting, rather than as we cover the pages, means all attendees get to hear the current discussion.
Modules of Mention
Learning Drupal coding through a Drupal web site can be enhanced using the modules "schema" and "table wizard". Module "data" displays tables in rows and columns, allowing mass editing of values, similar to phpMyAdmin. Re-mention of modules "devel" and "Drupal for Firefox".
Chapter 4 Review Part 1
These review notes revolves around some of the questions asked by various attendees as we went page by page through the chapter, sometimes jumping around. The order of these notes reflect this jumping (easier for me to transcribe my penciled notes).
1) Why clear just one of the two database menu tables? This question lend to my pointing out the Appendix A table schema might answer this question. Leading to this question:
What is the difference between the two database tables used for menus: menu_links and menu_router?
The involved Appendix pages were read by attendees at this time, and discussion centered on the foreign pointers from one table to the other. It was pointed out that callbacks appear to exist in only one table. And that one table may be dedicated to just links that are displayed on a page in a "menu", while the other table would also resolve URL pathnames defined in modules, not existing in menus (editable via the admin menu edit pages).
Yes, I could write this much clearer, but these notes take typing time. The rest is left as an exercise to the student. (inside joke)
2) index.php?q= is not a friendly URL, and is not considered part of the "pathname" for menu routing. Apache .htaccess mod_rewrite takes care of removing index.php from the visible URL in the web browser window. However, all modules need to be aware of this pathname 'prefix'.
3) Pathnames defined in modules do not need pathname 'folders' as a prefix. Any value without slashes can be used. However, collisions between modules can occur. Thus, establishing a 'namespace' for a module's pathnames, a prefix folder name, most times matching the module name, will avoid collisions.
4) Function hook_alter_menu() - Change callback for other module's menus. Last one wins. Except when Views are involved. Views always win. Why? Looking at core source, starting with hook_invoke_all() might answer the why Views wins question.
http://groups.drupal.org/node/161179#comment-543459
http://drupal.org/node/110238 gives "module weights", where weight values ranged form 3000 to -99. All core modules have weight zero. Function hook_alter_module_weight() can change the module's weight.
5) For the above two notes, module bad_judgment got invoked several times.
6) MENU_DEFAULT_LOCAL_TASK and MENU_LOCAL_TASK and concept of 'parent.' Implied parents based upon path name having a common suffix folder name. Explicit parents with array key #parent.
7) _to_arg - hook or callback or neither? How to find out?
Should Pro D7 Developer book use to_arg or _to_arg, like API.Drupal.org?
8) Path Folder names become hook function arguments - page 66-67. Use %map for all path folder names, when there are a variable number of folder names, like 10 to 120.
9) When display active menu with class=active - Done by menu or theme?
Superfish module does not have active menus being different.
10) $forms array key '#title' gives the link tag "a" text is also the displayed page title (Web browser title bar, bookmark, and displayed subheader above main content region).
There is a #title override function drupal_set_title() - page 73 - module code can use.
11) Page 71 - Array key 'access arguments' => '...', admin Permission page may display other text.
To find the actual value to check in PHP code: On Permission page view source looking for id=.
12) Function t() is not needed for menu item titles as its built into core. Page 72. Using it means t will be called twice, potentially displaying erroneous double translation.
Please add your own notes and corrections.
This completes the minutes.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
New Book from Drupal Design Camp Berlin
http://cocoate.com/ddbook states the deadline for session conversion to chapter was July 15, and the book will be out shortly.
Many, if not all the chapters are available in HTML format now, at the above URL.
I'll review the book chapters here, in this comment, as I read the chapters in sync with our book.
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
July 18, 2011 Meeting Minutes
LA Drupal User Group
www.LADrupal.org
Book Study Group
Meeting Minutes
July 18, 2011
Book: Pro Drupal 7 Development 3ed
Attendee Count: 13
Next Meeting Required Reading
Chapters 5 and 6, Database and Users, and Appendix A pages for Users of 604 to 620. Lots of user related tables.
Meeting Minutes
Everyone had read the second half of Chapter 4 on Wildcards. Only two people had read Chapter 5. Thus, the meeting ended at 8:40 PM, twenty minutes early.
There were a lot of side topics, not related to the book that came up. One was about LA Drupal organization structure and the parallels to the Drupal Association. I think it was useful to LA Drupal members to hear this. It was a one time off topic discussion worthy of 20 minutes.
www.Droplabs.net will be hosting a DCLA WebSite Building Sprint Tuesday at 4 to 7 PM lead by John Romine for the LA Drupal BIG yearly event www.DrupalCampLA.com
www.Droplabs.net will be hosting a Code Sprint this coming Saturday hosted by Ron. Look to http://Groups.Drupal.Org/la for details.
Due to a lack of focus on the part of the note taker, me, tonight's notes are sparse. Do add your comments to highlight something I missed. Or supplement the below with your own take, please.
Chapter 4 Part 2
% Wildcards
Three types:
/%/ - strictly positional
/%functionprefix/ - append _load() for full function name
%map - handle varying number of arguments, like Views does.
%index is part of %map, giving the foldername position in the pathname.
Chapter 5 Part 1
Covered just page 93 where Object syntax was used. Lead to a discussion about inserting table records. D7 has db_insert. And when to use function "drupal_write_record()" and that it never should be used. More info is available at: http://lists.drupal.org/pipermail/development/2010-December/036955.html
It was pointed out it might be used by a module to write to it's own custom tables, and use the Drupal table name prefix to support multisites in the same database.
Best practice to write a node is to use "node_save".
OO Lesson
Chapter 5, Databases, introduced new syntax, ->, ([page 93) that some were not familiar with. To bring the attendees up to par Paul did a brief tutorial on Object Oriented coding and syntax. Key points:
Object can be considered like an array with two types of entries:
1) Properties - same as variables, scalar values, numbers, text strings, and even arrays.
2) Methods - same as functions - getter and setters and more
The syntax varies for the two items above.
Also, the use of double and triple -> method invokations in one line, and what would happen if one failed to return the expected object was discussed. It was mentioned it might be bad practice to do this. It was pointed out in this particular case, none of the method calls could be expected to fail, unless the MySQL client went away, and then Drupal message area would hold additional error messages.
Log Out/Log In
Ron suggested a D7 exercise to code up the equivalent module to Christefano's D5 arriba derecha module for logging out. The idea is logging out should not always go to the Home page. Instead, intelligent destination= should be used.
The login form would be displayed, with the user id prefilled, in case the log out was accidental.
If the page was public, then logging out would display that page, as an anonymous user, which would aid testing when developing.
Other possibilities were mentioned, or combinations of them.
Something about "log out is same as log in" that I did not catch. Anyone? Do edit this, or supply a comment.
D6-7 Differences
Create Wiki Comment to list them as we find them.
Errata
We will add errata at www.drupalbook.com when we remember to do so at the end of each meeting.
D7 Cheat Sheet
Peter Benjamin will produce a visual aid of a "dream" format, where copy and paste to create an entire module might be possible. The idea is to format the cheat sheet in mostly valid PHP syntax, where array values might contain pertinent ranges of values for that array key.
Once the visual aid is examined by the group we might divide up chapters for each member to contribute to the final D7 cheat sheet.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Thanks
Thank you for taking the time and effort to keep minutes for the meets - its really helpful.
I second that!
Thank you thank you. This is a valuable list. I am a bot behind and having this page is a great help!
Study Group meeting tonight 8/8/2011
Hi All,
For those of you who weren't around yesterday afternoon at DrupalCampLA, we are meeting tonight and discussing chapters 7 and 8.
Paul
Paul Chernick
CEO
Chernick Consulting
(310) 569-2517
Drupalistas.ning.com Synergy Skype cast real time?
Hi Fellow Book Worms,
I'm still around. Almost made it last night, instead I spent more time on the Drupalistas Skype group call. So, I have some things to report about what Drupalistas are doing now, and what synergy between the two groups might happen.
I've had several people tell me they are following the LA Pro D7 Developer Book Study group via the minutes I have published. I owe one set of minutes, and if someone would write up the two last meetings.
Perhaps written minutes might be superceded by a webcast? Live? Archived?
I'm thinking of bringing my laptop, and webcasting our D7 book meeting over Skype, to those Drupalistas members who desire to listen in. Any supporters? Any complaints? If not, then I'll will un-officially post to Drupalistas, that after their 6 to 7 Skype call, there will be a 'test' Skype cast of our D7 discussion from 7 to 9. 3 hours on Drupal coding... some synergy.
Discussion?
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Homework based on each chapter ... or not
Hi,
Studying a book, to learn Drupal module coding, and never writing a module, is not my idea of solid learning. I know Tommy is coding all the chapter samples. I know Ali is coding many D7 modules as an integrated implementation of an existing API. Blake codes D6 already. I'm coding four D6 modules, and will be porting them to D7. Members ask to be supplied with homework modules to code up.
So, I asked Kathy, who leads up Drupalistas, if our members might code up the same proposed modules that her group has or is coding. She say yes. So, visit http://drupalistas.ning.com and see what they have posted there. I recall doing a download of one implementation.
I realized I could come up with some homework problems that would exercise knowledge from the chapters we are doing. I'll try that, too. Do not hold your breath. Please, your assistance is needed. I'll post mine proposed home here. They will be very simple.
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Possible Chapter Based Homework - Contrib modules Galore!!!
I can see a generic method that can be applied to most chapters to drive homework problems resulting in a contrib module for the motivated student.
The general idea is to "report" on what is found in the web site root folder or its database tables. This can be a useful troubleshooting tool, or used for learning, or site modification, to name a few. Already some modules exist that do similar, Table Wizard, Schema, and the like.
To jump right into it.
Cache
Give a list of tables with the cache_ prefix
-- flag those that are in core, or flag those that are not in core
--- this involves an understanding of D6, D7 and D8 core tables
----- How would this be done?
------ Hardcode the lists?
------ Read the list of core modules, and read their *.install, knowing that might not be complete?
------ Do both and flag where the data came from?
Give a summary of the row contents found in a cache table.
-- Would this be a selection list to get a report on?
-- Would a series of fieldsets to expand to see each report be better? Slower to gather?
--- Both?
-- What would be summarized?
--- Row count, minimum and maximum row size
--- Average row size, medium row size, standard deviation 1 and 2 from those
-- "Type" of row summary
--- How many delimited keys in the primary key
--- How many of each value of delimited key
--- Core and Custom summaries
-- Selective clearing by type, item, table, all tables
As you can see by reading what a Cache Report module might provide in the way of stats, not a complete list, by any means, providing other coders to contrib their needed stat, to our base contrib code, a cool thing involving many community members adding their needed 2 cents. There is a lot of design issues that could be talked about, but the 'base' feature set could be small as a homework assignment, and the functions created could form the core to be used to implement the rest of the functionality. Sure, some of it already exists, clear a table, but what did you clear? How long did it take? Stats might be nice to have for a high traffic site. Knowing the real impact of clearing. Being able to get a benchmark over time of how slow the site might be after a full or partial clear. Therefore, selective clearing, while it impacts the speed, might be done before a potential slash dot situation, compared to clearing the entire table, where slash dot would hammer the site as it fills the cache again. Useful right?
Why has it not been done before? A high traffic site has its coders doing more important tasks. Only a Study Group needing homework to hone coding skill and learn the knowledge would code this module. Many coding beginners could contribute as much of this module is not in a critical pathway for production.
htaccess
The same as the module "Libraries", used for ckeditor, jquery ui, and the like. Drupal upgrades often wipe out the htaccess local mods. Having Drupal maintain the local mods, and be able to prefix or append them back in, would be way cool, especially once 'drush up' included this method. Way cool!
Also, for nxing servers, the equivalent htaccess code could be maintained, or something, right?
Features:
-- Would this include a hardcoded set of all release htaccess files?
-- Would there be a git library or similar to compare/fetch each release htaccess file?
-- For core, both web root and default/files, and any other htaccess file
-- Support non core module htaccess files?
--- Backup and Migrate
--- backup_modules/, which drush moved out of the web root.
-- Report extra lines, changed lines, diff listing, side by side diff listing.
Lots of possible features. Again, after a minimum feature set is implemented, I expect the community to request more features, provide more code. Many coding beginners could contribute.
Erh, ok, you caught me. This htaccess module is not a book chapter. The only thing to do now, is to add your non chapter homework ideas.
Form Chapter
This could be complex, so I will just type in my penciled notes, and leave it at that. I had planned on expanding my notes, giving details, but time is pressing.
-- Count of each - list form
-- Number of forms
Now, the above features are word for word from my penciled notes, so may not make sense. Please add to them, refine them, correct them.
So, from these three examples, one should be able to see a pattern or two in the nature of these 'homework' problems. Mostly a reporting tool, with limited ability to change the database, or file system. With potential for future growth as a central place for beginners to add their name in creating a patch, to complete an issue queue feature request. Literally hundreds of patches over the next year or two, would fill in the feature set of these modules.
Just so it's known, I wrote a working D6 module with 1,000 code lines three weekends ago. My need to do homework is replaced with the need to write my second module as an ebodiment of my patent. By the end of September I should have another 3,000 lines written, and have ported by D6 module to D7. Designing software is my profession, so supplying thumbnail homework descriptions is an eye blink for me.
We've covered 1/3rd of the chapters. Lots of possible homework there, which I will leave to other attendees to define and post a beginning. Even that would be a worthy homework exercise, to do a thumbnail design for the first chapters, similar to the above.
I think each student should do at least one chapter 'design' and post it here. It only needs to be 5-10 lines long. And others can add to the bottom their features, or refine the posted features.
What to you say?
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Drupalistas Direction Update
I've talked with Kathy, the leader of Drupalistas, http://drupalistas.ning.com, during last night's Skype group call, and found out the direction their Drupal Module Learning has taken.
The group is now doing PHP coding from scratch of Drupal modules, not based upon any book or its chapters. The design of the module is the first step, defining the functionality, listing the required features. Much harder work.
Every Monday night at 6 PM PST, there is an one hour Skype group call, with participates spread across the USA, in English. Chat is used to set up the group call, and Kathy adds each person appearing in Chat to the group call in progress. New recruits introduce themselves.
New technology and cool apps that might be of interest to the members are presented, everyone goes to the posted URLs, oohs and aahs. Then, we talked about what we might do with it within the Drupal CMS.
A new module is being designed in the next few weeks to integrate an existing JavaScript that uses JQuery to making an amazing overlapping slide show. More on this next week, so I do not overly pre-announce. It's hoped over the next weeks this module is coded and might be a contrib module.
Note: Skype on Linux has issues, as only 2.2 beta is available, compared to 5.5 on Mac. Linux Skype Chat is limited, and you may drop out of the main Chat, but can join a new Chat, which those needing to send you text can join.
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Security with t(string,array(sub_values)) 3 Special Prefix Chars
The t() function supports two arguments, the first the string, the second is optional, an array of substitution pairs, variable names and their values.
There are three special prefix characters.
@ = Invokes function check_plain(sub_value)% = Invokes function drupal_placeholder(), then check_plain(sub_value)
! = No transformation - no security enhancement
The D7 book documents them on pages 468 and 470 with Figure 21-1 containing a flowchart.
The D6 book documents them on pages 456 and 457.
Typical Usage:
$output = t("My name is @variable_name", array( '@variable_name' => $user_value ));instead of the insecure methods of
$output = "My name is $user_input_value";
or
$output = t("My name is $read_from_database");
which both will allow possible JavaScript attacks upon the person surfing your web site or similar, that would be tracked back to your web site, not the attackers.
Function drupal_placeholder() is part of Drupal Core, and API function to surround the value with is ALL it does. The goal is to give coders a Drupal convention of echoing back to the user who submitted a form, their just inputted data in italics (apparently). Very simple.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Recap of August 22 and 29 Meetings
First, I've was unable to attend the August 8th and 15th meetings, and will not be posting any recap for those two events. I understand 2 chapters were covered at each.
The chapter rate is currently 1 per week, so August 22 covered Chapter 9 on Themes, and August 29 did Chapter 10, Blocks. My note taking at each of these meetings was slim, so below is my hazy recall.
September 5 is a US national holiday and there will not be a meeting. September 12 will cover Chapter 11, Forms, that is a large 54 pages. Many consider forms to be the heart of Drupal's API, user input for dynamic data. This event will have extensive minutes.
August 22 Themes Recap
Several PHPtemplate code examples has $attributes as a variable (html.php.tpl on page 197 - the body tag on the bottom line, html.php.tpl on page 201 - body tag, node.tpl.php on page 208 in the div tag, field.tpl.php on page 211 in the 1st div tag, block.tpl.php on page 212 in the div tag,), but this variable is not listed in any of the tables listing the supported variables for that one template. Nor do the documentation tables at drupal.org have it (them - see below).
So, we found it's real, and should work, by viewing the core code. (grep -r attribute modules/ is your friend.) It works similar to the $classes variable -0 see page 197. The coder populates an array called $attributes_array, storing each tag attribute ('parameter'=>'value') into the array. Drupal core converts the array to a properly formatted attribute text string using a separator of a single blank.
Now, the PHPtemplate field.tpl.php on page 211 has a 2nd and 3rd div tag, having $title_attributes and $content_attributes, respectively. These apparently work the same way, there being $title_attributes_array and $content_attributes_array. (typos mine - I ought to confirm the array names in the core source code).
To correct all those tables, I suppose the drupalbook.com errata should have this (pending - ugh, a lot of posts), and drupal.org documentation should have an issue posted (pending).
August 29 Block Recap
At 15 pages long the review was limited to one code error, on page 233, where f the $nbr_comments value returned from function variable_get() is empty or a blank text string, then the db_query will throw an error on invalid SQL syntax for the limit clause. There should be a conditional statement to include the limit clause or not in the SQL. A student experienced this error. And to follow Best Coding Practices, in the SQL statement, the lower case 'limit' should be upper case 'LIMIT'.
That concludes the book's technical content portion of the recap.
Our group's leader voiced the idea to the group to start doing D7 coding, and asked what problems might we solve. Many ideas were written on the white board, and a picture taken. I hope to see the items posted here shortly from the camera's owner. :-)
Two ideas that stick in my mind, that I wanted to be involved with are:
1) The drupal.org/project/examples could be added to. What a wide range of possible code snippets a student could do, with a fantastic place to publish the final code to benefit the Drupal Community.
2) drupal.org/project/cod could be ported to D7. We know San Diego is spearheading a D7 port via code sprints. To bootstrap our effort in joining their effort, I have posted 'must read' links, to catch up with their effort, at http://groups.drupal.org/node/154494#comment-573284, where the first two link pages are the technical How To pages on creating a dev environment, and what sub projects are available to port. Joining freenode #drupal-cod IRC chat was recommended as the way to start virtual porting a feature between Code Sprints.
We spent an awesome amount of time just having fun, chatting about a great many Drupal things. We watched an awesome demonstration by fellow colleague Blake of his truly amazing 3D java face rendering engine with Drupal front end that uses a real time neural network method.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
D7 Core UML Diagram URL
I found one by googling on 'drupal diagrams' - a silver mine of info.
http://upsitesweb.com/sites/upsites.co/files/drupal7_model_0.png
I'm going to print this out for my wall, as it tells me what core functionality is possible.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
+1
Great Find!
Thanks for sharing.
Meeting Minutes for September 12, 2011
First, it should be noted in the USA, a national holiday, called Labor Day, to celebrate the American worker, was September 5, and the group did not meet on this awesome holiday.
We covered Chapter 11 Forms, and a lot more. It's time to expand my minutes to include the "more." As I did not write any notes this time, neither for the Forms Q&A, or the "more", these minutes are sketchy. I was too involved in the Forms Q&A, and the "more", as much of the "more" was my initiation over the weeks of the meeting.
I find it hard to write comments that cover two very different aspects of a meeting, but I think it necessary here, as the Recap of the past two meetings had less than a handful of questions and corresponding answers, compared to our first meetings, where the Minutes took me 2 or more hours to type in, proofread, correct, refine, re-proofread, Preview, correct, Preview, correct, Preview, correct, and finally click Save. So, here I cover the organic growth of the meeting structure and the new sections we have added, going beyond review of the selected chapter material.
One of the purposes of writing these Minutes is to address the infrastructure aspect of running a Book Study Group that might aid other Drupal User Groups. I find it interesting the attendees have found more valuable topics to address other than the study material, and I note this for others planning on running a Book Study Group. Many attendees now come early or stay late to network, or solicit support for special projects, or just to chat and have fun. This activity has extended into the Chapter Material Review time, so fewer "on topic" questions about the chapter material are expounded upon.
Another purpose of these Minutes is to assist those reading these Minutes, about the Chapter Material covered, to aid in the learning and doing of Drupal Module Coding. Below you will find a mix of Form Q&A and new sections. Below find an "topic" list for each section, and below the list are the details of for the time we spent.
Section Summary
Section Details
Form issues that were brought and resolved.
What D7 code projects might a learning student do - see http://groups.drupal.org/node/158514#comment-578749 These projects focus on "reporting", not real creating nodes or such, as only a few chapters covers Nodes and creating them.
The Cache project above caught the imagination of Srikanth and myself, and has gotten off to a rocket start on how the both of us are going to define, design, code, and release this "homework" as a contrib module. Very surprisingly, code is already begun, a sandbox at D.O. is being set up today, and code check in will happen this week. Also, surprise, surprise, the value of this module has gone by several orders of magnitude with the new feature sets brainstormed in the last 24 hours. Expectations are every high performance web site and hosting firm will use our new "Cache Manager" module. Cool!
I will be delivering a list of more homework projects, that Srikanth took a picture of last week, a list of 'names', with the request each student pick one, and "design" it, no code, just list the feature set for it. This exercise is where any and all modules begin, an essential part of the implementation process.
I will be adding a per chapter list of possible projects, so a student can brainstorm features on 2-3 projects per chapter. I will first do Chapters 1 to 10, later this week.
An adhoc 30 minutes was spent near the end of the meeting achieving consensus that over half of the Book Study attendees wanted to prepare for a COD D7 Code Sprint, and time was spend on planning activity. A date was chosen. The decision that attendees would come 15 minutes to future Book Study groups and prepare their dev environment with both websites with COD D6 and COD D7 installed, learn git, and review the D7 Port Project pages to know what sub-project they would volunteer to sprint on. The idea is the day of the event, the experts would not be pre-occupied with doing extensive 'set up' on individual laptops, but the first hour would be spent on actual coding. Past Los Angeles Code Sprints I have attended had the leaders spending almost half the meeting time on 'set up' of the dev environment.
To support the COD D7 Code Sprint, 10 minutes was spend on talking about how easy D.O. git access was to set up for being a module committer and creating sandboxes. For the initial git instructions to do before our September 19 meeting, read this page http://groups.drupal.org/node/175504 entitled "COD D6 to D7 Port Wiki" that will be modified each week to include the needed preparation activities.
About 20 minutes (off topic dialogue between 2-3 attendees)
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE