From Habari Project
Step-by-step guide: Contributing to Habari with SmartGit for Windows
2. Starting Project -> Clone -> Select your fork of habari/habari Choose local dir to store files
3. Edit .gitmodules in your clone to point system at your clone of system instead of the habari clone of system
4. Commit the change of .gitmodules to your local repo and push it to your fork on GitHub
5. init submodule system Make sure the url points to your fork/account
6. Switch to master branch (already selected, but OK needed)
- Fork on the website
- Clone local
- Apply patches with patch -p0 < "patch_file"
- How to create patches?
- Commit and push
- Pull requests
- Fetch upstream changes
Go through commits per line:
- Switch to blame view
- Open the commit mentioned in the blame of your line
- In the commit, click on "view this file on <commit>"
- Switch to commit history view
- The commit is now on top and you can easily select to view this file on the commit before by clicking "Browse code" on that commit
- Switch to blame view again and repeat as necessary
Developing with Git
also see above
Some stuff about templates: Which are available, what do they modify (important: which element gets the id - container or input control!)...
More information on constructors. What can I pass to append, what can I leave out, and how the hell does insert work?
More information on storing. Why are there so many places where the storage method is null:null? (because it is not capable of detecting every weird place we want to store information in)
Searching code with GitHub Advanced search
Troubleshooting for Devs
- Something weird and unexpected happens in relation to something being null (invalid argument supplied for foreach etc). Might be because you use a filter and forgot to return the value...
- $theme->act_display() does not display posts when passing a paramarray and using a rewrite rule. Did you use keywords in the rewrite rule, like slug? Don't do that unless you actually want to match values from the URL against post parameters, Habari will try to get posts using those values.
Ideas for Addon catalog
Should be groupable by categories (but optional).
Missing the "latest dev version" block we talked about somewhen.
I would like a very simple "Is this compatible with my Habari version?" thing. We could add two options on the overview, like, "show only stable releases", and "show only stuff compatible with Habari" $DropdownBoxHabariVersions or so.
Also, we might want deprecated information. Like, this thing provides a dash module, but dash modules are out, so use this plugin instead that provides a dash block. (Feature versions?)
Definitely needs thumbnails. Nothing is more annoying than having to click empty names to see what the theme roughly looks like. Also, display the screenshots in a larger view on the detail page.
should be separate for plugins and themes.
We should have some "related" list on the detail pages that not only includes addons with similar tags but also plugins that are related by feature.
I guess we want some basic categories and then additionally tag the stuff. Who will be doing that?
Also, assigning to multiple categories should be possible. Like in the following, podcast would get content types and media.
Suggestions for plugin categories: content (types), comments, import/export, post collections (like featured articles, recently commented, latest posts, think of a better name for that), dashboard, editing (wysiwyg, code snippets, autop etc), media (silos etc), social (like the Github login I recently made), admin tools, miscellaneous. Those would cover all the plugins I use on my sites.
For themes, we might rather work with just tags and let users filter themes by tags. Like, show only themes tagged with two-column, sidebar and responsive. More suggestions: multicolor, single-column, multicolumn content
I don't know how many themes there are yet. I could imagine to separate them in more CMS-like themes and more blog-like themes. For example, the Namibia theme I cloned from Joomla does not have comment support yet (but if I added it, it could be used for both, so "suitable for cms" and "suitable for blogs" could also be just tags).
Git users and addon catalog
- Get GitUsers branch from Konzertheld/post_receive
- Reactivate the plugin (triggers new stuff in activation)
- Get Konzertheld/githubauth and remove namespace
- Get Konzertheld/socialadmin (0.9 branch)
- Get Git API stuff (register new application, put client id/secret and redirect uri in githubauth options)
- Trigger post_receive (the last commit should be yours). Github Test button is helpful
- A user will be created with the pushed repos author as username and linked to the authors Github account
- Log out
- Go to login form and click Login with Github. You should be able to log in with OAuth and edit your addon :)
- The publish form is broken for me, btw. Feedback if others experience that is welcome.
Alternatively, you could add http://base.konzertheld.de/addons/update to one of your repos and then send a ping via the Github Test button. That should be enough to allow you to login to http://base.konzertheld.de/addons with your Github credentials.
I wonder what happens to the password. I don't set one and Habari seems to disallow login without password generally, but who knows...
- Which users should have edit access? At least the one who created the addon, what about others who contributed to it?
Stuff to code (Wanted Addons List)
http://drunkenmonkey.org/irc/habari/2013-03-17#T17-20-09 (explanation of OEmbed before that point)
Comment statistic details - who commented most
Make a term a child of group:
$vocab = Vocabulary::get("feeds"); $term = $vocab->get_term("httpwwwhasencoredefeed"); $group = $vocab->get_term("groups"); $desc = $group->descendants(); $vocab->move_term($term, $desc);