This article is a stub. You can help the IndieWebCamp wiki by expanding it.
selfdogfood is a specific form of dogfooding, that is, using your own creations on your own personal site that you depend on, day to day.
Metaphorically speaking, a person's ideas must be the building he lives in - otherwise there is something terribly wrong. Søren Kierkegaard, introduction to Provocations
Selfdogfooding has several required components, the first two of which it shares with dogfooding:
Posts about selfdogfooding (most recent first)
Use and development
Are there two dimensions to selfdogfooding: use and development?
A: There are many required aspects of selfdogfooding, use and development only two of them.
Content updates but no commits
Would a site that is regularly updated with posts but not have commits for a while qualify as selfdogfooding?
A: At some point if there are no creative (code, UX, design) commits by the self-identified primary user of said site, then they've shifted from dogfooding (which requires a creation/use feedback loop) to simply being a user. No, eventually, after "a while", that should not be considered selfdogfooding.
What about sites that are running non-open-source software (no way to directly verify commits)?
A: Even web sites running software that is either little or not at all open sourced can still be analyzed for what features they use in terms of :
Thus even if specific code commits are not transparently visible, there are plenty of other direct and indirect sources of evidence for creative (code, UX, design) changes, and thus the create/use pairing can still be verified to some extent.
testing your code in production
Whilst testing your code in production is a good part of selfdogfooding, security precautions should still be taken. Showing errors, warnings and notices usually reserved for dev environments is a huge security risk due to the fact that things like paths, usernames, secret keys, etc. might be inadvertently shown to anyone who cares to look. It’s also not a great idea to have confusing error messages intermingled with content.
Rather, you should log all such messages somewhere where only you can see them, or only show them in-page if you’re logged in as an admin.
In PHP, there are several ways to go about this.