habari / habari Goto Github PK

Initially reported by: @msi as #TRAC584
What is included?

1. The login form in the sidebar can be displayed as Login header tab or it can be hidden. It's a configurable option in the new theme configuration.
2. You can select external styles in the theme configuration. You just need to create a "styles" folder with your CSS files, or create sub folders with your CSS files and images.
3. Because #TRAC571 (2nd version) is not yet discussed, I removed that feature but the theme is ready for and can be changed.
4. Disable the comments for pages if no comment was written and if comments are disabled. This is not exactly #TRAC579 because I did not disable that output for regular posts.
5. If the user is logged in, the comments form will not display the fields name, mail and URL. They are hidden. You just see your username and you have a Logout link.
6. Two new functions in "theme.php" to create the comments link (parts taken from Charcoal) and the "Edit Entry" link in the related templates.
7. The tags template has a header "Tag Archive for %s" now, and the home template displays a date archive header (if necessary).

Any suggestions?

Initially reported by: @Heilemann as #TRAC456
The quick upload form in the toolbar of the media silos doesn't work. I'd 'display: none' it for the silos where it isn't expected to work for years ahead, but I need the classes from #TRAC450 :) -- For the Simple File Silo, it should be easy to make it work, since it already has working upload.

Initially reported by: @sean as #TRAC560
Selenium-based tests help find problems that a user would encounter (not expected functionality like unit tests, but actual user experience).

It would be nice to have coverage of everything at http://wiki.habariproject.org/en/Test_Procedure in a Selenium test suite.

Here's a general framework, and coverage of the Content section of that wiki page. I'll write up a simple howto and commit it to this repository:

https://svn.caedmon.net/svn/public/habari-selenium/

(I realize CS isn't Habari's, but that can be fixed if you choose to import)

S

Initially reported by: @RandyWalker as #TRAC417
Implement a system of content "places" where content can be displayed:

List of places

1. blog chronology
2. page
3. one or more locations defined in the active theme

Create content by choosing the desired content type and before publishing, choose a "place" for the content.

Examples of theme-defined "places" could be an about block in the sidebar or a colophon in the footer.

A way of dealing with switching to a theme with fewer "places" would have to be developed. Show on the theme page how many "places" each theme has so the user can see before switching.

See this thread for discussion: http://groups.google.com/group/habari-dev/browse_thread/thread/f051ff1992ff710a

and: http://groups.google.com/group/habari-dev/browse_thread/thread/f93d5d8abc85d5d7/9aa28926fb15049e

and after message 11 in this thread: http://groups.google.com/group/habari-users/browse_frm/thread/1307c4ff94407478

Initially reported by: @Arthus as #TRAC551
The first-run tour doesn't look as nice as one would expect.

I think it should visually tour each element of the menu bar.

Look at the attached screenshot to see what I mean.

Initially reported by: @michaeltwofish as #TRAC540
Habari's AtomPub implementation should support media collections.

I think the way to do this would be to expose a collection in the service document for each silo, and the AtomPub implementation simply creates an interface to, for example, Flickr.

Obviously not all the silos will implement the full CRUD; I'm not sure how we'd deal with that.

Initially reported by: @Heilemann as #TRAC360
As per this discussion: http://groups.google.com/group/habari-dev/browse_thread/thread/6fe40f774bb1bcfb, the Humanized Messages system needs to be refitted to align it with the original concept: http://flickr.com/photos/heilemann/2276080347/in/set-72157603941330603/

This is actually a series of sub-tasks, that go something like this:

• Allow for persistent messages.
• Move the log 'tab' and make it less intrusive.
• Allow for multiple simultaneous messages.
• Tweak time-to-fade.

I'll happily do the design and CSS/JS enhancements, but the persistency issue probably needs some backend work.

Initially reported by: @justincwatt as #TRAC15
''Moved from GCode Issue !#TRAC88''

'''Reported by justincwatt, Jan 11, 2007'''

Would be nice to have post validation, which would be necessary for
outputting atom's type="xhtml" with any confidence.

'''Comment 2 by moeffju, Jan 25, 2007'''

Would that be validation as in 'is valid XML'?

'''Comment 3 by moeffju, Mar 28, 2007'''

If OR doesn't reply, I'll assume this refers to checking wellformedness.

A XHTML validator would probably out of the scope of the project, but it should be
possible to implement validators as plugins.

Checking wellformedness only makes sense for X(HT)ML output, so it should probably be
part of a plugin, too.

'''Comment 4 by freakerz, Sep 01, 2007'''

To fully support APP, we would have to be able to take HTML and turn it into XHTML,
in case a user serves XHTML and posts HTML, it won't break his site.

The APE tests that feature, and in our case, doesn't work.

It would probably have to be an InputFilter.

Initially reported by: @michaeltwofish as #TRAC186
Habari should cache produced HTML rather than reproducing it on every request.

For historical perspective and discussion on caching, see #TRAC43.

Initially reported by: @morydd as #TRAC217
I'd like to see a way to choose different sizes of images to put into posts via the Flickr Silo

Initially reported by: @ringmaster as #TRAC617
Habari doesn't discriminate imported posts from new posts. As a result, imported posts may incur additional pingback execution or other unwanted plugin behavior.

Habari should note when it is importing, and plugins should be written to be import-aware.

Initially reported by: @trevorturk as #TRAC20
''Moved from GCode Issue !#TRAC112''

'''Reported by trevorturk, Jan 14, 2007'''

It would be nice if you could put everything in the /htdocs directory aside from index.php
and .htaccess into a subdirectory called /habari (or whatever) and then have the site work, much
like putting all of the WordPress files aside from index.php and .htaccess into a folder called /
wordpress would work.

'''Comment 2 by robin.adr, Jun 08, 2007'''
Or:

/
/index.php
/habari
habari stuff goes here.

That would be a nice default layout.

Comment 3 by robin.adr, Jun 08, 2007

Well, an .htaccess in there, too.

Initially reported by: @Heilemann as #TRAC455
You can't search any of the media silos. Ideally, doing a search should create a temp 'folder' of search results, with the title of the folder being something along the lines of: "Search for 'foo'", which would then contain the results. And in the same manner as the 'Photos' folder in the flickr silo, only a batch should load at first, and scrolling to the right should load a new one, and so on.

Initially reported by: @lildude as #TRAC805
Rewrite rules needs to redirect "end-slashed" or "non-end-slashed" entries to a consistent URL.

Lets take two representations of the same URL:

http://domain.com/my-entry

... and ...

http://domain.com/my-entry/

At the moment Habari treats these two as separate URLs by returning a 200 response code for each, and (rightly) the same content.

Habari should however stick to a uniform URL format and redirect (301 or 302) the other URL format to it.

So, for example, all URLs will be "end-slashed" or not.

I hate to say this, but Wordpress uses the 302 method to redirect to "end-slashed" URLs.

This is important for things like search engines which will treat the two URLs as different URLs containing the same data and will index both.

Initially reported by: @Heilemann as #TRAC453
It'd be nice if the error messages in the simple file silo were using the message system. For instance, trying to create a directory named '/' will create an error.

Initially reported by: @bcse as #TRAC668
Format::apply() only support string arguments for now. When a formatter has many arguments, it would be a pain to use them. I propose to allow array as an argument, too.

e.g. Format::apply('image_title', 'post_title_out', 'helvetica.ttf', '18', 'black'); could be change to Format::apply('image_title', 'post_title_out', array('font' => 'helvetica.ttf', 'size' => 18, 'color' => 'black');

Initially reported by: @Heilemann as #TRAC371
Currently the way you add a media item to the content area is by double-clicking it, which will then apped its code-snippet to the end of the content area.

But it is the intent of the silo's that it should be possible to drag a media item onto the content textarea and drop it in the right place, which would then insert the proper code at the cursor-position.

I've had a crack at it, but I was unable to figure out how to track the cursor position, and thus couldn't figure out how to insert the code snippet in the correct place.

Initially reported by: @michaeltwofish as #TRAC580
To minimise unnecessary transmission of data, Habari should support the HTTP ETag header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19) and If-None-Match (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26).

Initially reported by: @dmondark as #TRAC613
Discussing the possibility of having themes include plugins as well. It would be necessary to state which plugin is actually being used and it's version (ie. Version X.Y, from theme Abc, Version X.Y, from the user directory...etc), or something similar.

Initially reported by: @nicerobot as #TRAC801
If the installation is occurring under a password protected directory and the .htaccess file isn't writable, installation will attempt to verify the rewrite rules by calling RemoteRequest to fetch /check_mod_rewrite but that will fail.

There is no indication that 401 is the error. The installer just keeps failing saying that the rules don't exist and .htaccess isn't writable.

Workaround is to make .htaccess writable during the installation.

Possible solution might be to add a rule to .htaccess to ignore protections for check_mod_rewrite, at least during installation.

Initially reported by: @arickmann as #TRAC650
I have just used the following Where condition to import a single category from a WordPress blog.

I haven't written a patch because this is only applicable from WordPress 2.5 and the plugin description says it supports 2.3.1 but if you do want to add it in future this will get the posts from a single category given the category ID.

$where_condition = "WHERE post_type = 'post' AND wp_posts.ID IN (SELECT DISTINCT object_id FROM wp_term_relationships WHERE object_id IN (SELECT object_id FROM wp_term_relationships inner join wp_term_taxonomy on wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id WHERE term_id = '16'))";

Initially reported by: @moeffju as #TRAC724
My Habari (@2740) logs database errors like:

PDOStatement::execute() [pdostatement.execute]: SQLSTATE[HY000]: General error: 145 Table './database/habari__sessions' is marked as crashed and should be repaired in system/classes/databaseconnection.php:268

as module=Error, type=default, severity=any, when it should probably be module=habari, type=database, severity=error.

Initially reported by: @rickc as #TRAC644
If one is not using Habari's multisite capability, the config.php for a new installation is created in Habari's root. The root of /user would be a better location. This would help maintain a clean separation between system and user files, get one more file out of the root directory, help prevent accidental deletion or mistakes during upgrading, and make backing up of user files easier. In conjunction with #TRAC273, there would be a total separation of user files and system files.

Initially reported by: @LEW21 as #TRAC744
It's impossible to translate %s Comments correctly to languages that have more than one plural form.

Initially reported by: @Heilemann as #TRAC454
In the flickr silo, when you're in the 'photos' folder, only a small batch of photos. Ideally, scrolling to the extreme right should load one more batch of photos. And so on. Much like the way Google Reader loads more items as you scroll down.

Initially reported by: @skippy as #TRAC439
The Habari log should be used to record more of the goings-on throughout the site. For example, the Media Silos should record actions -- particularly the Simple File Silo and the creation of new directories and uploading of items.

Initially reported by: @chrismeller as #TRAC358
This ticket will serve as the base for Oracle DB support.

Initially reported by: @davidcubed as #TRAC735
It would be nice if there was some form of "help" or something to understand what Content Address means.

Initially reported by: @ringmaster as #TRAC166
If installing on lighttpd, the installation should not, for example, mention having mod_rewrite enabled.

Initially reported by: @ringmaster as #TRAC769
The tags field on the publish page should autocomplete or suggest options as you type.

Initially reported by: @RandyWalker as #TRAC162
"Habari Community" themes need a home on hp.o maybe at /plugins or /plugins/plugin-name

Initially reported by: @msi as #TRAC571
I have this enhancement to create author URLs to display posts of a specified author. It's a new rewrite rule and a new action. If you change your theme code like

{{{
"<a href='" . URL::get( 'display_entries_by_author', array('author' => $post->author->username) ) .
"'>" . $post->author->displayname . ""
}}}

you will get a clickable link.

It works, but I don't like the idea of using the user name. WordPress has a so called ''nice name'' for the URL slug. I would like to have the same here in Habari, because my user name and the ''nice name'' are different. It's for security because a potential attacker will think both are the same. ;-)

Initially reported by: @michaeltwofish as #TRAC645
Our resident brewer, scoates, has hinted that he will brew a Habari beer, but we need a name for it. If you've got a clever geeky idea for an ale, a lager, a pilsner, or anything else reflective of Habari, pitch it here.

Initially reported by: @ayunyan as #TRAC385
The pingback plug-in cannot treat PingBack transmitted from the blog which uses multi-byte encodings other than UTF-8.

Initially reported by: @Arthus as #TRAC833
The ajax plugin actions/hooks are extremely useful, and we should have a generic (non-ajax) version of this.

Essentially, it would comprise of 3 parts:

1. A new rewrite rule: http://habari.base/file/{type}/{context}
2. A handler for said rewriterule, which sets the file header-type to {type}, with shortcuts for css, js, etc. and then calls the appropriate plugin action.
3. Plugin actions in the form of action_file_{context}($type, $handler).

Initially reported by: @ayunyan as #TRAC796
this patch adds import feature from WordPress eXtended RSS to WPImport plugin.

Initially reported by: @tinyau.vampire as #TRAC39
''Moved from GCode Issue !#TRAC303''

'''Reported by tinyau.vampire, Apr 03, 2007'''

I hope future version of Habari can support user define permalink
structure. As a user of WordPress currently, I hope to retain the
permalink of the posts when I migrate to Habari in the future.

Duplicates: #TRAC467

'''Comment 1 by [email protected], Apr 17, 2007'''

http://groups.google.com/group/habari-dev/browse_thread/thread/bf21fb65f3a5ecc/936fbb2e9af48195?lnk=gst&q=wordpress+rewrite&rnum=1#936fbb2e9af48195

'''Comment 2 by freakerz, Sep 19, 2007'''

Is this still a desired feature?

Maybe we could move this to a -dev thread, talk about using rewrite rules to support
more than one permalink? Would that cause some conflicts?

This would probably fall under the "plugin" category.

'''Comment 4 by freakerz, Nov 03, 2007'''

Should we supply the users with a core feature as described or leave it for a
plugin? (kind of what I did with Route301, add WP permalink support via custom
RewriteRules)

Initially reported by: @skippy as #TRAC211
When an administrative user sets filters on any listing that supports filtering, those filter selections are lost when they navigate away from the page. For example, if a user filters /admin/content to only show drafts, the next time they visit /admin/content they will be shown published entries, forcing them to re-filter the listing.

I propose that the values used to filter the display be saved in a userinfo record, so that subsequent visits to those pages preserve the filter settings. Using a userinfo record ensures that the settings remain across user sessions.

Initially reported by: @Arthus as #TRAC793
You should be able to extend comment types and statuses, just like you can extend post types and statuses. We should implement the methods "Comment::add_new_type" and "Comment::add_new_status". This would be useful for plugins to store other data as comments.

Initially reported by: @chrismeller as #TRAC824
While individual users can have their own timezones, it doesn't appear that the HabariDateTime class currently takes that setting into account.

The issue below is no longer relevant, but there is a new one: When clearing the search box, you get an "Uh oh, an error has occured". --Konzertheld

Initially reported by: @wilcosworld as #TRAC561
Refering to the manage page or manage entry section of the admin screen.
When you are searching for something using the search bar, and then hit the 'X' clear button, then select another value, (draft, published, scheduled, entry or page), the search box updates to reading "Type and wait to search for any entry component status:published".

As a side note, when you hit the 'x' clear button, it should un-select that search values selected.

Initially reported by: @Heilemann as #TRAC404
Currently you can either simply type in the search filtering commands manually, without help, or you can press the 'buttons' underneath the search bar on the manage pages.

I would like to help build a system that throws out the buttons and replaces it with an auto-complete system.

It would work like so: When you click the search bar, your cursor is placed in it as per usual, and below the field, a box with the available filter commands drops down. This would contain stuff like author, date, content, state, type and so on. You can either use the arrow keys/mouse to select on, or start typing. As you type, the ones that aren't matching what you're typing will be filtered out.

Once you have a filter command, like for instance 'state:', another list drops down, namely with the values available for that command, like unpublished, deleted, published, draft and so on. Now you can select one of those.

This will make the system nearly infinitely extensible, fast and elegant to use while remaining relatively user-friendly.

I'll work on a design suggestion asap.

Initially reported by: @chrismeller as #TRAC346
Often (mainly in WP-land) one will, after several years, have thousands of entries in their options table. Most of these options are left over from plugins long since deactivated.

The common opinion seems to be that, upon deactivation, a plugin should delete anything it added during its lifetime. For options and configuration data this is no major loss and can easily be re-created, should the user need.

While working on the plugin directory plugin, I was uncertain how far to take this approach. On deactivation, should it delete all plugin directory entries? That could be a lot of data (read: thousands of custom posts) to be lost accidentally.

After a discussion in IRC, it seems the best idea may be to add a 'delete data' checkbox when deactivating a plugin. This would sorta emulate the Drupal deactivate vs. uninstall functionality.

For bonus points, allowing the plugin to specify (somehow) that this box should or should not be present would eliminate some extra confusion and allow plugin authors ultimate control of what happens with their data.

Initially reported by: @gsnedders as #TRAC497
Currently, the formats we allow for tags are quite complex. It'd be nice to simplify these. To quote my email of September 2007:

1. Double quote + non-whitespace character + any character except double quote + double quote + non-word character or end of string.
2. Space or start of string + single quote + non-whitespace character + any character except single quote + single quote + non-word character or end of string.
3. Any character except for comma.

Initially reported by: @mikelietz as #TRAC480
Trying to validate a textmulti's URL triggers formui warnings about preg_match expecting a string, not an array. The validators need to check for an array. See attached patch [for one feeble attempt. See attached IRC transcript for what this really should be].

Initially reported by: @Arthus as #TRAC828
Currently, our mass deletion for 1) comments, 2) posts, and 3) logs is extremely slow. It has 2 bottlenecks, one in finding the items to delete, and 1 in actually deleting them.

I have started a patch which improves speed considerably. However, a few functions need to be added to the Posts and EventLog classes. These functions should be similar to the Comment::delete_these($ids) method.

Initially reported by: @chrismeller as #TRAC823
In order to turn off all comments, you currently have to disable comments on every existing post and remember to turn them off on every new post.

There should be a global option (through the Options page) to disable comments globally. I would think disabling the comments checkbox on the post create / edit page and adding a little note about them being globally disabled would be nice.

Initially reported by: @chrisjdavis as #TRAC61
''Moved from GCode Issue

Reported by chrisdmitri, Oct 16, 2007

What steps will reproduce the problem?

1. create a sub site that is NOT a sub-domain
2. run the installer
3. witness the brokeness. Specifically the links and refs all point to the root site, not the subsite. Additionally post data is not displayed.

What is the expected output? What do you see instead?

To have a working sub-site

Comment 1 by smerrill, Oct 16, 2007

Site::get_url() mistakenly uses the parent directory for the URL, rather than the
(non-existant) sub-directory. I expect that Site::get_path() suffers similarly.

There exists in the Site class a property to define the install type (local, sub-dir,
and sub-domain). The Site class needs to be updated to determine the install type
and generate URLs and paths appropriately for each kind.

Comment 2 by chrisdmitri, Oct 16, 2007

Could/should that constant be moved to the config.php of each sub-site? We are already requiring the rolling of
configs by hand, I don't think that adding this to the config would be that big of a deal.

Comment 3 by smerrill, Oct 17, 2007

I'd prefer that config.php not have any notion of what kind of install it is. For
example, if you decide to take your sub-site database to a new host as a fresh
non-multi installation, I don't think you should have to change anything in
config.php (save maybe the database credentials) in order to keep Habari working.
Put another way, Habari should be smart enough to figure out what kind of
installation it is on its own.

Similarly, Habari should be able to determine the path(s) and URL(s) necessary for
running a sub-site in a sub-directory. That means that we'll need to unspool the
directory name in /user/sites/ in some way.

Comment 4 by smerrill, Oct 17, 2007

I added this to Site::get_url() :

                    case 'habari':
                            $url= Site::get_url( 'host' );
                            $path= trim( dirname( $_SERVER['SCRIPT_NAME'] ), '/\\' );
                            if ( self::$config_type == Site::CONFIG_SUBDIR ) {
                                    $config_dir= basename( Site::get_dir('config'));
                                    $host= substr( Site::get_url('host'), strpos(Site::get_url('host'), '//') + 2 );
                                    $tmp= str_replace( $host, '', $config_dir);
                                    $tmp= str_replace( '.', '/', $tmp);
                                    $url.= $tmp;
                            }
                            elseif ( '' != $path ) {
                                    $url.= '/' . $path;
                            }
                            break;

That works for generating the correct link for get_url('habari') for sub-sites in
sub-directories. Unfortunately, it does not properly account for user and theme
directories, which do not necessarily live in /user/sites/x.y.z/. The code above
also doesn't properly handle sites on non-standard ports.

Hopefully the above will be a useful starting point for someone looking to fix this
problem more completely.

Comment 5 by epithet, Oct 27, 2007

Trying to make the subdirectory sites work has led me on a strange journey through
the interdependent wonderland that is the Site class, ending at the conclusion that
the class needs more general work than just fixing this one issue.

We should consider how we might centralize the way values are constructed for return
by the Site class, and then build functions that return those values. I think this
will yield more readable code than trying to build the output from within each
function. We could call an ::init() somewhere at the beginning, so that there would
be no question about dependencies. And in the case where a directory changes
depending on whether it's present at the root or a sub-site, the process that does
this could be clear and centralized.

In any case, this "small" thing,even if we don't rework this class, is much bigger
than we should wait for 0.3. Pushing to 0.4.

Initially reported by: @moeffju as #TRAC726
Any page with the timeline/list schema should have navigation above AND below the list. When scrolling through a list of comments, I currently have to go back to the top to click Older. I'd like to have the older/newer/timeline replicated at the bottom and clicking Older/Newer should change the page and take me to the top.

Initially reported by: @Arthus as #TRAC470
We are putting a lot of useful code into admin.js which themes would potentially want to take advantage of. I propose we split up the code into multiple files so themes can call only the needed files.

For instance, many themes might want to implement comment moderation directly. Instead of making them write a whole new script to do so, they should be able to add the comment moderation js to the stack.

Since we have WSSE authentication on all ajax caller functions, security wouldn't be a problem. However, some rejiggering of functions would be required (the themes might not used the same ids and classes for display).