Hello, my name is: Amy

OpenCamps - Word Camp

Back at Open Camps this weekend! For a bunch; WordCamp, Angular Camp, and FrontEnd Camp. But... I may or may not actually go out again tomorrow for Angular/FrontEnd because trekking to the UN exhausts me and I'm starting a new job on Monday. (wooHoo!)

Here's most of the notes I scribbled down:

Word Camp

Sponsors (that I looked at, there were a TON.)

Jetpack

Free plugin that takes care of everything 'else'. Meaning things like image cacheing (using WordPress.com CDN), stats, social sharing. Seems interesting, so I'll have to check it out and play with it for a while. Not sure what the relationship is with wordpress.com.

SiteGround

WordPress hosting. OMG there were so many options that were there. This one caught my eye because they were having everyone fold boxes to enter a drawing. I have a weakness for packaging, okay.

Interesting idea, I suppose I would use a different hosting on a real live site, but for what I'm doing right now I'm OK with just using my Digital Ocean server.

Hover

Domain names. Didn't really know that where you buy your domain name from was really all that important.

Building a Better WordPress through Software Archeology

This was a talk by Boone Gorges, talking about the best way to make contributions to a large scale open source project (like WordPress).

He noted that it is important to look though the history of a project when you first jump in.

WordPress Tools

Step through bug history.

Basically you want to go back to where the first time was that the bug was introduced. (annotate/blame can help apparently).

Use git to find things

  • git log grep string - searches commit for posts on whatever string you enter
  • git log -S - searches the diffs to find a specific string, once you find the commit number, then git show
  • git bisect - If you don't know where to search for the error, this is a pretty slick way to do it. Basically, you tell git where it was good, and you know where it is bad. Git will pick a point halfway, and you tell git if the bug is there or not. If it is, then it splits the area to the right, if not, to the left, and it continues until you are able to find the point where the bug was introduced.

Content Strategy from Disovery to Wireframes

I hopped into this talk by Marguerite Halley for a bit, but it might have been against my better judgement as I had already been through most of this before (reading the A Book Apart Book, The Elements of Content Strategy).

  1. Discover
  2. Insight (Analytics) - Pouplar pages, referrers, keywords, landing pages. What do users ask the most? Be a little bit careful with this.
  3. Information Architecture - Think outside the org chart. Use a card sort technique (have users write all the items out and organize them on index cards.)
  4. Create text only wireframe - what content, what functionality, what links and to where. have users look at these!
  5. Content priority diagram, main wireframe - if you are freelancing, have client sign off on this, detailed wireframe.

All the Colors of the Internet

Conversion Tools:

Use symbols AND colors. Never just color.

Introduction to Plugin Development.

This was a pretty basic intro into plugins by Bruce Chamoff. I had been through most of it by watching the fabulous videos over at Develop with WP

Basically you only edit wp-content folder, nothing else. he listed out some of the actions/filter hooks that he uses:

Actions

  • admin_menu
  • init
  • admin_init
  • admin_notices
  • wp_dashboard_setup
  • admin_bar_menu
  • wp_enqueue_scripts
  • show_user_profile
  • edit_user_profile
  • personal_options_update

Filter

  • the_content
  • admin_footer_text
  • body_class
  • login_header_title
  • wp_footer

These hooks determine what parameters you'll be able to use in your callback function.

These are the WP API's he uses mostly (I have very little conceptual idea of what it actually means to use these, though I might have actually done so in the past.):

  • options
  • transients
  • metadata
  • theme customization
  • shortcodes
  • widgets

Making changes to an Existing Plugin

If you have a plugin that you've found that you need to adjust some of the current functionality:

  • If it's a large plugin you'll probably be able to hook into the plugin just like you hook into WordPress. This is the preferred method. If this isn't available, then perhaps you could contact the developers and see if they'd be willing to implement, or steer you in the right direction.
  • If it's a small plugin, then you could just use require to include it if it is set up in an object oriented manner.

Security is not an Elective

This was my favorite talk I saw! I enjoyed George Stephanis's sense of humor a lot.

  • Don't use open wifi (w/o a VPN)
  • HTTPS your things
  • use good passwords
  • use a p/w manager
  • don't rely on fingerprint login
  • don't trust your users.

Writing Secure Code

Something about 'timing attacks', where you need to use hash_equals() when doing comparisons if ( hash_equals( $var1 === $var1) ).

Sanitizing is in regards to the content, and making sure that what is input is what it's actually supposed to be.

escaping is in regards to context:

  • attribute
  • html
  • js
  • sql
  • url
  • textarea
  • raw

If you ever need to fix a security issue, make sure that in the fix is ONLY the security issue. Also probably a good idea to contact security@ and plugins@wordpress.org so you can work together to see if other plugins might suffer from the same problem. That was a release can be timed if necessary.

Comments