=============================
- Interesting talk about testing your API code to be as dev-friendly as possible (tested/documented/etc.). UX Testing where the developers are the users.
- Stories about WordPress themes and the like.
- We need more themes / people making more themes
- Theme review team - make.wordpress.org/themes
- Contribute to the WP Core
- Theme review team - make.wordpress.org/themes
- Follow WP coding standards
- Andrew Mason's talk about querying in WP - see starred tweet
- Slides: kovshenin.com/wcsf2013
- marquee tags (demo +1)
- text-align:justify; for grid layout. pretty nice possible option, check it out (IE8+) … still some issues though, I still prefer floats (until Flexbox is fully supported).
- Designing CSS Layouts With Flexbox Is As Easy As Pie, by David Storey on Smashing Magazine - http://coding.smashingmagazine.com/2013/05/22/centering-elements-with-flexbox/
- slides on joshbroton.com
- codex.wordpress.org/Translating_WordPress
- slides: http://chroni.ca
- Preventing "Clickjacking":
- JS Framebusting (not reliable due to framebusting-busting)
- A Better option (modern browsers) X-Frame-Options: Deny (http header) works IE8+
- Another method for older browsers (classic browsers)
- Better non-JS option XXE?
- None of these are foolproof. Need to prevent substitutions.
- Use libxml_disable_entity_loader() along with one of the above options - see video/notes again
- WordPress has request libs available?
- PHP doesn't handle it's stuff securely by default. We need to take the extra steps to make this happen.
- Reading:
- phpsecurity.readthedocs.org
- owasp.com
- http://cdn.ly/publications/busting-frame-busting-a-study-
- Reading:
- WordPress as an app platform. More applications being powered by WordPress on the back end.
- New developer resources - developer.wordpress.org
- debugbar plugin recommended to check out
- Uses WP itself to perform operations
- Can use system cron and bash scripts to automate stuff
- Manage All The Things!
- Update WordPress
- Install/Update a plugin
- Change/Manage themes
- DB Exports/Backups
- Cron jobs to update themes - really only safe with chid theme setups
- Search/Replace text in DB!!! Holy Smokes
- Resources
- WP-CLI:
- wp-cli.org
- getsource.net/tag/wp-cli
- halfelf.org/2012/command-line-wp
- CLI Cheat Sheet:
- files.fosswire.com/2007/08/fwunixref.pdf
- WP-CLI:
- https://gist.github.com/helenhousandi/1573966 (Taxonomy Overload fix)
- Tim Bray, Private By Default
Andrew Nacin (@nacin, nacin.com, nacin@wordpress.org)
- If using version control - which you should be .. you aught to just disable the admin wp-editor. See slide.
- Reading (Codex):
- map_meta_cap()
- WP_User
- WP_Role
- register_post_type()
- get_post_type_capabilities()
- core.trac.wordpress.org
- View Tickets
- Tags
- Before opening a ticket, search the the Trac to see if that issue already exists. (core.trac.wordpress.org/newticket)
- Common procedure of opening a ticket … very descriptive in issue and how to replicate, if applicable
- Very similar process to Redmine issue tracking.
- Keep version to where issue was originally discovered.
- If you know how to fix, add has patch. if not, add needs patch.
- Your dot-org login is what you would use for your Trac login
- View Tickets
- How to patch/submit a patch to the ticket.
- Upload a diff with git or svn from the root directory of your local setup.
- pipe your diff into a file and upload that file
- use patch [ticket-number].diff as filename and extension
- new patches to same patch will be incremented by .2, .3, etc. do not have to do manually, trace will do this if name is exact as an existing.
- use patch [ticket-number].diff as filename and extension
- pipe your diff into a file and upload that file
- Upload a diff with git or svn from the root directory of your local setup.
- Version on GitHub is trunk and safe to use.
- If bug is security related, DO NOT open on Trac - email security@wordpress.org with issue and communicate that way so that vulnerabilities are not in the open.
- Best way to test a patch:
- Apply patch
- Search for bash scripts mason if I want to use CLI for patch testing. OR
- Manually download patch from ticket
- use patch (the program): patch -p0 < [filename-downloaded.diff] (example: patch -p0 < 2345.diff) - now local truc install has patch in place to test - can now test/make changes/upload updated patches - do not be offended if someone has a better solution for your patch. people will make more efficient updates to your patches. it's cool - try not to add unrelated files/fixes - debug bar & debug console plugins are great and should be installed - do it! - Plugin called developer that looks to make it easy to track or recommend good plugins? - Search theme unit tests - can find an XML import of dummy content and useful stuff. so check that out too.
- Apply patch
- Set up install just like you would any other new site.
- If issue is already marked as has patch, still leave a detailed comment still to any new patch update so people following are notified and there is a documentation trail. Holla!
- Once patch is done, there's still a process afterwards:
- tons of tix and still needs review, etc. there are just not enough people to go through all of them.
- go to the #wordpress-dev IRC channel on free node. paste in ticket number and let them know that you put a patch up, if you want to draw attention to a particular issue that you have already put a patch in for. keep in mind, you have worked on this ticket so it may be a little more important to you than to the rest of humanity. plead your case a lithe if you really believe that it is an larger issue.
- Not a bad thing to have multiple people working on a ticket. sometimes people take different routs to a solution and sometimes the actual best result is a blend of more than one person's solution. so it's NOT like, "I'm working on this, don't touch!"