denisdebernardy

above described problem is solved.

I’m experimenting a site who is aggregating over 50 sources with no lag: the trick is to use the cache and to update the feeds at shutdown.

rust: did you forget to cache or something? ??

normally, you don’t need to do _anything_ besides:

1. activating the plugin
2. creating a page (NOT a post) with a slug of “home” (typically: create a page titled home and rename it immediately after)

could you describe the problem more precisely?

either you fetch the data directly in the DB and process it locally, or you fetch the preprocessed data that WP returns. WP happens to return the preprocessed data in XML (rss, atom, rdf, as you see require). there is no better way to do what you want to do than with rss.

~10 of them?

i suspect it is forgetting to remove them.

i personally kept both the category and the date archives:

<shameless_self_promotion>
Semiologic.com
</shameless_self_promotion>

the date archives is mainly for search engine purposes — i understand google doesn’t index deep pages on PR-0 sites. i suspect most users won’t use them.

for categories, i divided them into three groups:

– data types (e.g. columns, weblog, digests…), which i use for global nav

– main topics (e.g. artificial intelligence, knowledge management), which i use for archives

– sub topics (e.g. machine learning, natural language processing), which have a main topic parent, and which i use for contextual nav

in order to render category and date listings more usable, i decided to fill and display the exerpts after quite a number of trials and errors. in the end, i’d say i sticked away from the standard blog format, and i’m quite happy with the results.

i still think there are usability problems. but they are mainly due to the absence of relevant autolinking and the lack of a relevant search engine in wordpress, so there’s nothing i can do about it in the short term.

hopes this helps.

$posts = get_posts(‘offset=0&numberposts=5&category=2’);
foreach ($posts as $post) :
start_wp();

will make it work better

i’ve a similar problem with the_date()

are you sure you got the trackbacks right?

to pingback, when available, simply put an html anchor with the permalink and everything will occur automatically.

to trackback, copy the trackback url and manually paste it in the “Send trackbacks to:” field within the ‘write post’ tab.

come on macmanx, you know better:

experimental psychology tells us the average human is mostly blind to details he is not specifically looking for. thus, users never have, never do, and never will read instructions. they only become interested in docs and instructions when they experience problems, and they usually don’t spot them when not actively looking for them. hence, the importance of contextual docs.

moreover, users seldom look for docs at the right place because the average human spontaneously asks a person when he runs into problems (e.g. when you start looking for a new supplier, you ask your contacts first). hence, the suggested bold links before the download button and in the forum. it is the extra step that might make a user aware docs exist in the first place.

regarding the security issue, i’d appreciate if you enlightened me, because i see no obvious security holes here: you can review the upgrade.php code before opting to upload it to your blog. and from where i’m standing, resulting potential security holes looks very much like an arbitrary “machine is clueless, so user is in charge of choosing the best defaults” position. if it is, i’m afraid the later is irreconcilable with my “user wants to stay clueless, so machine is in charge of choosing the best defaults” position, so i’d rather not turn this constructive thread into a sterile debate.

anyway… i’ve to admit i’m just an average, clueless, originally irritated newbie that does not read readme files. and my contribution to wordpress, today, is the time i spent giving a few hopefully constructive suggestions here and elsewhere that i think could streamline wordpress, its docs and its support workflow.

from there, you are just as free to ignore said suggestions entirely on grounds they were not worth the time you spent reading them, as you are free to read more such suggestions by subscribing to my blog’s columns, which occasionally deal with usability and wordpress, among various other topics. ??

thanks for your time — Denis

sure, it is very simple indeed… if you’re aware you must do it. and as i just pointed out:

– there might be a few ways to organize the information that will make more users aware of the solution.

– there’s even a way to bypass the difficulty entirely

podz: yeah, i know. i’m in the software business, i perfectly understand your point, and i sincerily don’t want you — or moose, ryan, matt, or any other developper — to take anything personally.

regarding your remark, documenting software is not so much about producing pounds worth of paper than about producing a tool that requires little or no documentation in the first place. as an aside, and quite frankly, i think wordpress itself is not very far from being idiot-proof.

now, user-oriented workflow and general estaethics put aside, the main focus to make the software more usable is to provide contextual help. simply put, no amount of codex pages — which works very much like an html encyclopedia — will replace the right line at the right place (with a link to said encyclopedia).

hence, i can only i disagree with you: criticising from the sidelines is one of the best ways to contribute when it comes to contextual help. more so when it tries to be constructive. irritated “i was trying to do this from there… it did not work as expected!” type reports, no matter how unconstructive, should prompt an immediate “why was the guy trying to do it from there in the first place?” followed by a “how do i make this more obvious?” when relevant. and the only way to usability test thereafter is through trial and error until said irritated reports disappear.

example (and reply to macmanx):

“how come we got so many users who did not run wp-admin/upgrade.php when upgrading from 1.5 beta to 1.5”

[thinks hard]

1. because as a rule said users never read the readme file

2. because said users stopped reading the installation instructions when they found the download button

3. because said users expected no major difference between 02/11/05 code base and 02/17/05 code base, only bug corrections

4. because said user assumed upgrade.php would automatically run itself

[thinks hard for steps to increase usability]

1. as a rule, users only read docs that are short and simple, i.e. to do blah blah go there, do this then that and click apply. 1 line for title, 4 bullet points of instructions at most (*). write more and only the bravest will read.

2. strategically put installation instructions before download link, and put link to faq and codex — nevermind: to “Frequently Asked Questions” and “Documentation” — towards the top of every page in the support forum.

3. put warning in bold on download page because it is really not obvious. see 4, however.

4. change upgrade procedure

a. store current version and last backup date in options table
b. auto-run upgrade.php and auto-backup user data without even asking the user whenever necessary

(*) there is a reason for 4 at most.

as you probably know already, users can manipulate 7, +/- 2 pieces of information — or groups thereof — at once without any problems. it is the reason you’ll more easily memorize the second of the following:

3 – 6 – 2 – 7 – 9 – 4 – 6 – 9 – 4 – 8

36 — 27 — 94 — 69 — 48

7 – 2 = 5, so you’re safe with close to all individuals by choosing 5.

however, there’s an equally important yet much less known experiment which shows 4 is the maximum number of items you can apprehend without counting. this holds for animals as well (e.g. a bird can count to 4). consider how many there are:

III

IIIIIII

IIII

IIIII

like a bird, you count 1, 2, 3, 4, lots! except when you concentrate. and users are no different. hence, 5 bullet points need a lot more extra effort than 4. so we choose to stick to 4.

From then, you can group and most users will not even notice the complexity. they’ll notice even less if the details are accessed using html anchors. consider:

1.

– a.
– b.
– c.
– d.

2.

– a.
– b.

3.

– a.
– b.
– c.

4.

– a.
– b.