Any chance to integrate D4B (Drupal for Bloggers) before the 4.5.0 code freeze?

http://james.seng.cc/wiki/wiki.cgi?Drupal_For_Bloggers

It seems that at least one D4B patch has been accepted into Drupal, but the process appears to be too slow.

The vanilla drupal-4.4 has only barebones blogging features. I've seen users accustomed to Movable Type and other popular blogging platforms kinda shrugging at Drupal, saying it does not provide features that they consider essential for a modern blogging software.
D4B seems to fill this gap; it adds powerful blogging extensions to Drupal, and the same users who are used to blog via MT and other apps said that Drupal + D4B is essentially equivalent to MT from a functional perspective.
Especially nowadays, after the changes (restrictions) in the licensing of certain blogging applications, there's a rather large user base in search for a good, free blogging software. Drupal + D4B could meet this need, if only the migration of the D4B patches into Drupal could be accelerated somehow.
I'm no Drupal or PHP expert at all, but from the little i can tell, the D4B patch does not seem exceedingly invasive. It affects the blogging components (obviously) and that's almost it.

I first experimented with Drupal as a blogging software, but it was barely usable (after being used to the "big" blogging apps).
I migrated then to D4B, which was much better, i had no problems so far, but patching Drupal at each and every new release with the D4B patch is a waste of time. A Drupal already containing D4B would be awesome.

Thank you in advance.

Comments

killes@www.drop.org’s picture

Well, Drupal is much more than just blogging software. So people that only want to blog will find difficulties.

I tried to find the patch you speak about, but was not successfull.

Dries’s picture

We already integrated some of James' work into HEAD and I'd like to integrate more of it ... some of his patches are pending in the patch queue (but no longer apply).

What are the most important improvements from your point of view?

florin’s picture

Well, it's hard to say. "All of them" would be the honest answer. There are so many things that "simply work" in the major blogging applications, including Drupal for Bloggers, and most users probably won't give up on any of them.

If i had to make a piecemeal choice though...
- the various features related to image uploading in the upload module
- fixes and cleanups to the generated XML feed
- the feature-complete blogAPI (the MT functions)
- the RSS feed is much closer to what the search engines expect, and also there are aliases to it that map to popular filenames of the RSS feeds used by other blogging applications (search engines search for them - without those aliases some search engines will miss the plain Drupal's feed)
- various tweaks to the taxonomy module that make sense in a blogging environment
- improved ping module (increases the blogosphere's awareness of your blog)

All these things appear quite natural and actually seem to be essential requirements if you're blogging a lot.

And just to make my point clearer:
I'm aware of the fact that Drupal is a lot more than just a blogging software. But that's precisely why it's so attractive. The point is, the blogging part of it is rather sketchy right now. Or, maybe not "sketchy", but not quite so actively developed and improved.
Drupal for Bloggers is pecisely the needed improvement to bring the blogging component up to the same level as the rest. As a plus, it's made by someone who's up to speed with all the good ideas in the blogging world.

--
Florin Andrei
http://florin.myip.org/

Dries’s picture

- the various features related to image uploading in the upload module

I'm looking for a 'document management module' (images are documents) for inclusion in core. I'll give James' upload.module a try.

Can you shed some more light on the item below:

- the RSS feed is much closer to what the search engines expect, and also there are aliases to it that map to popular filenames of the RSS feeds used by other blogging applications (search engines search for them - without those aliases some search engines will miss the plain Drupal's feed)

What do search engines expect? What aliases?

jseng’s picture

google, feedster and msn crawlers look for index.rdf, index.xml and xml.rdf by default. It is useful to aliases index.rdf to node/feed at least.

Dries’s picture

I just checked the 404 reports here at drupal.org and you're absolutely right. How did you setup these aliases? Simply using the URL aliasing (path module) or did you registered a new handler using menu()?

jseng’s picture

nope, i just do a simple path alias of index.rdf to node/feed. No need to make it more complicated then neccessary.

I did fix the RSS feed tho. Drupal CVS split out 'broken RSS' (not broken but rather one the crawler wont be able to understand) so you never get indexed properly.

Unfortunately, no, it is not in the patch queue. The patch is dependent on many other little patches (xml exception handling in node.module) is dependent on other stuff (blog.module patch) in the queue. At the rate my patches is been accepted, I think it would be a long time before I can get to this.

florin’s picture

I did fix the RSS feed tho. Drupal CVS split out 'broken RSS' (not broken but rather one the crawler wont be able to understand) so you never get indexed properly.
Unfortunately, no, it is not in the patch queue. The patch is dependent on many other little patches (xml exception handling in node.module) is dependent on other stuff (blog.module patch) in the queue.

James, am i correct to assume that this was the main reason why my vanilla-Drupal based blog never quite got as popular with aggregators as i was expecting it to be? (by comparison to an MT-based implementation)

Among the three biggest visibility problems with vanilla Drupal (RSS format, alias to RSS filename, and ping module) which one do you think it affects visibility the most, and which one the least?

--
Florin Andrei
http://florin.myip.org/

Dries’s picture

Some data that might be of interest:

mysql> SELECT COUNT(wid) FROM watchdog WHERE message LIKE '%rss.xml%';
+------------+
| COUNT(wid) |
+------------+
|        222 |
+------------+

mysql> SELECT COUNT(wid) FROM watchdog WHERE message LIKE '%index.rdf%';
+------------+
| COUNT(wid) |
+------------+
|        223 |
+------------+

mysql> SELECT COUNT(wid) FROM watchdog WHERE message LIKE '%atom.xml%';
+------------+
| COUNT(wid) |
+------------+
|        219 |
+------------+
Prometheus6’s picture

I'm aware of the fact that Drupal is a lot more than just a blogging software. But that's precisely why it's so attractive.

Exactly right. Right now I'm running a pretty typical blog, but I have archival stuff I want to keep readily available. The book.module is pretty much perfect for that; no blogging software has anything like it. Stories are excellent too, and though other portal package allow user moderation they don't have the combination of features Drupal has (side note: it took me a couple of days to wrap my head around Drupal's API. I still don't know what's going on inside the Nuke variants. That's another reason I like Drupal)

I think fixing and enhancing the blogging functionality would be a good move because if you look around many of the newer commercial sites feature blogs. They don't give away anything by way of CMS functionality, they just add (at least something that looks like) a blog.

cel4145’s picture

And the story module can be better for some types of weblogs than the blogs module. For instance, I prefer to use the story module for my personal weblog because I don't like the "so-and-so's blog" link that merely points to what I'm publishing on the front page already. And with a multi-authored community blog, such as a Slashdot-like community site, one might not want to have separate RSS links for each user (consider the potential server load). Or one might want to use the story module to run a community weblog on the front page where posts are automatically published and promoted, then allow some members to have individual weblogs interior to the site which are not promoted to the front (a setup I use for class sites). So I, too, do hope that whatever changes are implemented benefit, not cause a detriment to, a variety of Drupal site usage beyond just the blogging module as bloggers will benefit as well.

florin’s picture

I prefer to use the story module for my personal weblog because I don't like the "so-and-so's blog" link that merely points to what I'm publishing on the front page already.

I had exactly the same complaint, but it was apparently ignored. I ended up hacking Drupal myself, to not display that link, but it's kinda annoying to do that at every release.
I still think that that link needs to be made optional to the site administrator.

It's just one more example that shows that Drupal needs a bit of improvement on the blogging side of things. Otherwise, it's already outstanding.

--
Florin Andrei
http://florin.myip.org/

cel4145’s picture

i never complained because i figured out that except for the blog-it link in the news aggregator (which i find not very useful for me), there was no discernable reason to use the blogging module for an individual blog. after learning about drop.org, i realized that the blogging module was developed around the need for multiple blogs in one site. in all other cases, the story module makes more sense, imho.

Dries’s picture

The blog module is really a 'multi-user blog module'. I'd be happy to (re-)consider a patch that helps make it a 'single-user blog module' as long it can be both.

florin’s picture

Yes. I think there's the perception that Drupal is "good enough" for blogging, which is obviously not, especially if you compare it to full-fledged blogging apps.
OTOH, Drupal is already an outstanding content management tool that surpasses many other similar apps. With proper blogging capabilities added to it (like the ones offered by Drupal for Bloggers)... well, it would be hard to ignore it.

And maybe there's also the perception that Drupal for Bloggers started out as a "fork" to Drupal. That's again incorrect, i discussed this with James Seng (the D4B author) and he's more than willing to integrate D4B into Drupal proper. It's just that he probably needs a working platform to test his improvements in a live environment, hence the D4B tarball that looks like a Drupal fork but it isn't. It's just a more convenient way to attract beta testers and iron all bugs out before submitting changes to Drupal.

Right now, i'm not using Drupal simply because it doesn't fit my needs w.r.t. blogging. I wouldn't use it simply as a blogging tool, but it's the blogging component that keeps me at a distance.
OTOH, depending on D4B makes me feel uncomfortable - that's a pretty small project and i'd rather use something supported by a large community, such as Drupal.

Overall, i can only see good things coming out of merging D4B into Drupal.

--
Florin Andrei
http://florin.myip.org/

cel4145’s picture

Yes. I think there's the perception that Drupal is "good enough" for blogging, which is obviously not, especially if you compare it to full-fledged blogging apps.

I'll disgree for a couple of reasons:

To repeatedly express the idea that Drupal is not good enough for a majority of blog users is incorrect. Tens of thousands of bloggers use Blogger, Blog-City, and other free blog applications (remember Web Crimson courtesy of Corante?) that are not superior to Drupal except in ease of use (and sometimes not; ever user Blogger about a year ago before Google started reworking it? argh!)

Advanced bloggers, then, I think is the real audience that you are speaking of as a target for Drupal blogging improvements. It may be true that Drupal lacks some features that they would desire. But I also know some advanced blog users that are very happy using Drupal, instead of MT or other blog apps (I'm not sure what all the "full-fledged blogging apps" are). They appreciate the advantages of the commenting system which allows user registration and threaded commenting (as well as searchable comments), the built in news aggregator, the sophisticated taxonomy system (Drupal had it long before most of the other blogging apps even had categories), category specific RSS feeds (also a first for Drupal), the book module, etc. Now I know this is the point that Prometheus6 was making above, but I suspect that many bloggers find Drupal lacking because it has a different feature set, one they are unfamiliar with, and as they become used to it, will see that Drupal is a better web-publishing environment. After all, that's what a blog is: a simple web-publishing engine. Advanced bloggers should be open to the range of possibilities in a more complex web-publishing engine rather than just looking for features they are already familiar with. There's a worthwhile trade off going on here.

So, IMHO, Drupal's just next generation in terms of overall feature set; some are just not fully developed enough (for example, Atom in core and Seng's captcha would be nice). In fact, the closet thing to Drupal is Manila. For instance, a year or so ago when MT was first starting to catch on, Manila was the top blogging app out there. If Manila development (a) had not stopped and (b) was not built on a proprietary web server app instead of LAMP (and, consequently, not built to run on 'nix), we'd be talking about Manila as setting the standard for blogging applications. But I'm sort of rambling now :)

jseng’s picture

whats the point of arguing it is good enough when there are users specifically say Drupal is not good enough. The fact some of them find it useful enough does not negate the fact others dont.

You can choose to listen to the user or you can choose to ignore them. And I choose to listen to them and make it useful for them.

sepeck’s picture

I have been playing with Drupal for a few months now. I am not a developer/blogger/coder. It has been a learning experiance.

Good that you are listening to your users. Good that you are contributing patches. The feedback that I have seen are requests that you follow submission guidelines for patch submissions so that your patches can be considered on a more granular basis for their impact of aspects outside of blogging sites.

Well, I supose blogging would be nice, but I like Drupal for it's Content Management Capabilities. Blogging doesn't impress me, nor am I concerned with it or all that interested in it. So, if you want others on board, how does integrating all your proposed patches improve Drupal overall in addition to the blogging aspect?

File handling (I noted Dries postive comment to your implementation above) and better image handling interest me. I have seen some of the improvements in a not yet integrated image module (http://cvs.drupal.org/viewcvs/contributions/sandbox/gordon/image/) that I will probably test on mine and a friends site. I am now looking at how to deal with files (zip, pdf, etc). How does blogging help me? Not at all. I appreciate the cautious and thoughtful approach to consider how proposed changes affect the rest of Drupal.

I have one site that (design not optimal but light years ahead of her current site) that the customer is happy with. She will not be doing blogging. My friends site will not be using blogging (though what he will be doing is very blog like -photography and family/friend/hobby articles). A friend had me throw up a demo site to show his boss for a posible corporate CMS for inhouse documentation tracking. And mine, which I hope to use as a knowledge base of tech articles I find interesting that might have a blogging setup if I can figure how it would be better then stories/pages.

I have seen a lot of good contributions (suggestions, usability/work flow, to patches) come out of this MT licensing fiasco. I hope to see more. I also like that it's impact on other core functionality is considered before moving forward with acceptance.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

jluster’s picture

Yes. I think there's the perception that Drupal is "good enough" for blogging, which is obviously not, especially if you compare it to full-fledged blogging apps.

Show me some areas in which Drupal isn't "full fledged". And please, please, don't show me some MT "this is what blogging is" ideologies such as "extended text". Fact is, blogging is an activity. You could call vi a "full fledged" blogging app, it allows you to maintain a reverse chronological website. No, Drupal is just right, non-partisan, non-exclusive. Making it "more of a blogging app" would make it less of a useful piece of software, and we don't want that, do we? :)

Again, I am using Drupal as a "blogging" tool, and I don't miss a single thing.

Overall, i can only see good things coming out of merging D4B into Drupal.

Literally dozens of contributors submit patches and features all the time. If you tell me, what you think would make Drupal a better "blogging" app, I'll personally hand-code it and send it to Dries.

--
http://www.jluster.org

Steven’s picture

I don't see Drupal 4 Bloggers integrating completely any time soon. The impression I got from one of the proposed patches was not good: Drupal 4 Bloggers introduces a bunch of inconsistencies and 'quick hacks' rather than looking for proper globally-Drupal solutions. In other words: it is not invasive, but for the features it is adding/changing, it should be.

For example, its blog.module completely disregards the filter system flow and replaces it with a custom one. This is not good, because if I was using Drupal4Blogger I would expect the same input processing everywhere. The advantage of using Drupal to blog is exactly that you can do more than just blog, so doing specifically blog-only exceptions doesn't make much sense.

The same goes for its excerpt/summary/extended body handling: again blog.module-only.

But when people point this out to James Seng, all he seems to do is "Ok, I don't care if you don't want this functionality in core then.". This is not true, we just prefer to have it in a cleaner, more uniform method like the rest of Drupal. If we start adding specific features in random places, we end up with a PHP-Nuke-like spaghetti of code duplication.

moshe weitzman’s picture

It takes work to get a patch integrated into Drupal. This patch is not there yet, nor does its author appear to have the persistence to get it there.

Steven mentions a couple flaws which prevent it from being committed at the moment. Addressing those flaws is a big job (mostly in consensus building) but unfortunately is a prerequisite for inclusion in core.

jseng’s picture

i have no problem with valid critisim. and if there is a problem with the patch, i will fix it.

but when you think you can make someone beg to get code to get to be included, its time you pay a visit to your shrink. i am not that desperate to get my code into core and no one gave me any reasons why i should be either.

killes@www.drop.org’s picture

The problem I see is that I do simply not understand why you not only want the teaser to be handled differently (which I can understand), but also want an additional summary field. This seems to violate the Drupal principle of making everything as simple as possible but not simpler...

The reason that this might be present in some blog application isn't really that convincing to me.

jseng’s picture

because every blog system out there, every std blogapis, and every other features known to the bloggers is dependent on having those fields. without those getting into blog.module at least, i can submit no other patches. now, as you said in the IRC, thats probably what you like to happen.

your dislike of bloggers is not a reason to refuse the patch.

robertDouglass’s picture

Hi James,

could you please reference the standard blog APIs which you are talking about, and where I can go to inform myself about how they work w/ regards to Drupal? Thanks.

Good luck getting your patch through!

- Robert Douglass

-----
visit me at www.robshouse.net

killes@www.drop.org’s picture

It's correct that I think that blogging as such is a bit overrated. I however did not say that you shouldn't contribute patches. Now that I know why you want to have those fields, I at least understand the reasoning.

In this light I think you should rather go back to an extra table for blog.module and override the default teaser in the _load hook. We'd then only make sure that your teaser in nor overridden by the standard teaser mechanism:

if(!$node->teaser) $node->teaser = node_teaser($node->body);

in fact I recall that I had submitted a patch sometime ago to do this...

cel4145’s picture

Not sure if these systems are using automatic teasering like Drupal, but consider what fields are provided in standards input interfaces (note that I used opensourcecms for some of these findings and may not have the most current release):

  • Blogger does not provide anything but one field for users in it's posting/editing system (ever notice that a Blogger blog doesn't have teasers or summaries?).
  • Blog-City provides one.
  • Nucleus 2.0 provides two.
  • WordPress 1.01 provides one.
  • b2evolution 9.03 provides one.
  • bloxsom uses a standard text file as input without the "multiple fields." a bloxsom user informed me that the additional functionality might be available as a plugin.
  • Manila has one field.

pMachine and MT are the only ones that I know of which have the three fields available to users in the standard input interface.

Dries’s picture

Because every blog system out there, every std blogapis, and every other features known to the bloggers is dependent on having those fields. without those getting into blog.module at least, i can submit no other patches. now, as you said in the IRC, thats probably what you like to happen.

Based on Charlie's (cel4145) information, one field is more common than 3 fields ...

If Blogger has 1 field only, BloggerAPI support is a non-issue because it has been created by Blogger.

In the same vein, if Manila has 1 field only, the metaWeblogAPI is a non-issue because it has been created by the Manila folks (Dave Winer).

James, can you explain why future patches heavily depend on having support for multiple fields (and where these APIs come into play)? Say, the blog changes were committed to HEAD, what would be the patches that depend on it?

cel4145’s picture

i only looked at the text fields available in the user input interface. it could be that those applications are breaking the posts up and storing them separately (although, i'm fairly certain it would be safe to say that Blogger does not). also, WordPress had a new 1.2 release in may which might have implemented those other fields. i think Manila had an update recently, too (the installation i went from was about a year old, i believe). however, they haven't done any serious improvements to Manila in a long time, so doubtful that this would have been implemented recently.

which leads to a point i tried to make above (in the point that drupal is good enough for blogging). it's not useful for this conversation to include bold, grossly general statements that seem more rhetorical than fact. to claim that "such and such" is a standard, when it's either (a) not in use in a majority of apps or (b) a very new feature, is, imho, not useful for this conversation. it could indeed be included in a standard somewhere, but if it's not yet implemented widely, than this "it's a do or die for blogging" attitude is nonproductive.

instead, it would be more productive for bloggers arguing what drupal needs to stick to presenting ideas about what is most useful. for example,

  • my feeling is that the latest comments block would be an excellent addition to core. a similar feature seems popular on MT blogs, and i've seen that it stimulates increased commenting, and thus interaction, on the drupal sites i maintain. bloggers like increased commenting (as do other communities). similarly, drupal really could use a way for users to view recent comments by registered user, since in may sites, some users only participate through commenting. the functionality is in drupal, but not made available to users. note that it would expand the "features" of commenting for registered users, offering something that other blog software doesn't have.
  • then there's the captcha module seng has built for anonymous comments. without that, the MT like anonymous commenting option built in for drupal is almost useless since it leaves drupal sites open for comment spam.
  • a blogroll for each blogger. profile module should include a field (or two) whose text/html appears as a block only on the user's blog listing, user listing page, and on their individual posts visible to all users. blogrolls are very basic blog features and such a field(s) would make it easy for bloggers with a little html savvy to implement. it may be that the bookmarks module does make some of this possible (i honestly have not tried this module and perhaps should), but users also like to be able to create a custom block for their blog that might contain text or a greeting.
  • i'm sure that there are more
Dries’s picture

Each of your suggestions can be added easily. I'd be happy to include (some of) these in core. I'll implement and commit a comment block to HEAD later today. Why not add an 'edit'-tab to each user's main blog page (blog/x) where he or she can configure the suggested features? Let us cook up some more patches ...

cel4145’s picture

it make sense to include the edit tab there so that a user will realize that they can make those changes, as long as they can also get to it through their "edit account" link.

as for the user-customized block proflie suggestions, it could work best not to be blog-centric in considering this, but rather user and community oriented. in other words, if it displays as a block on the user/view page and with an individual's post (whether blog or story), then there are other communities who might want to turn this feature on. for example, maybe drupal.org? some of the site designers and developers might be able to create a personalized block that features text and links to their work. or maybe not :)

so it might be best to avoid the term "blogroll" if the field was targeting a link list. maybe " links." (also, sometimes bloggers include links to other things, so it might not be strictly a blogroll). of course, eventually, it would be nice for users if the block title were customizable by the user. but that could be saved for later versions and updates.

when i mentioned two blocks, i was envisioning that eventually it would be nice if one were a blank html/text block, and the other used a form which asked users for urls and titles (no html necessary from the user), then created the blogroll for them (seems as if some of the blog software does this). but once again, this would be something to think about for later versions :)

Dries’s picture

I added two blocks to HEAD: a 'recent comments' block and a 'categories' block.

cel4145’s picture

both of those are great additions that bloggers will like, too :)

jseng’s picture

Drupal as the current stage is fully compatible with BloggerAPI and partially compatible with metaWeblog API. It is not compatible at all with MT API.

If you count by # of codebase, then sure, MT APIs lose out. But if you count the number of users using MT vs all the rest add to gether, MT install base wins out. (I remember a market survey conducted and MT has more install base then all the rest added together)

Thus, the majority of the bloggers are used to certain features in MT, and anything less is asking them to settle for less. Now that you have Drupal, would you settle and go back to *Nuke?

By which, the body handling is only a tip of the iceberg. And no, none of the stuff you mention are particularly high on the priority (not even my captcha but i am in the process of writing it as an independent module for 4.5 but thats another story...)

It is the little little stuff that MT bloggers are used to, mostly usability features.

1) Top of the list is Convert Line Break. I am aware that several people dropped their 4.4.1 and used D4B just for this feature. When I said Convert Line Break, I dont mean just pass it along nl2br which Drupal does it right now. That's not good enough.

2) And then of cos, there are stuff like multiple trackback and autodiscovery trackback pings which is also taken for grant.

3) Anonymous comment is also an important feature but Drupal already has it.

4) a way to easily upload files/image (hopefully in a separate popup window so it dont interfer with the content they are typing in the main window) which generates html codes they can cut and paste into the entry. Personally, I rank this one of the top feature, one I used very very regularly. (ie, upload.module but i still have no way to slot in javascript to do popup window in drupal)

Look at some of the MT users wishlists. I scan them regularly and you would be surprise how little they care about 'the ability to have blogroll' (most already using blogrolling.com) or 'ability to shift menu around' (most of them don't even know html, seriously which is why upload.module generates the html after uploading the file for them to cut-and-paste).

There are others of cos, but these are little stuff but dependent on how the rest of the system behave wrt to fields, anon comments, etc.

I dont mind my patches not going thru. (When my anon comments was not accepted into the core and someone else did, I backtrace in v0.6 and make D4B v0.7 compatible with drupal anon comment fields instead).

We can also argue over the design: whether to do it across the whole system, or just in blog.module or how to do it properly, or what names to call it etc.

But dont throw out the features users request. There is a reason why they ask for it..the fact you dont understand it doesn't mean they dont need it.

florin’s picture

It is the little little stuff that MT bloggers are used to, mostly usability features.

Yes, i see your point.

On my list, at the top are the "visibility" features. Mainly, the improved ping module in D4B, and the fixes to the RSS feed (the aliases to the file name plus fixing the RSS format itself). Without these, a Drupal-based blog is, for the search engines and the aggregators, quite difficult to "notice". Visibility (or lack thereof) is a pretty blatant issue, one that becomes evident once you step outside the Drupal "box".
As i installed a vanilla-Drupal 4.4 and started to play with it as a blogger, i watched in dismay the 404 error codes piling up in the logs as the blog crawlers were visiting the site.
I feel that this is an important enough problem to require a 4.4.x bugfix release before the start of the 4.5 series. But that's not my call, of course.

Add to that the D4B improvements to the image uploading and i'm almost willing to forget the rest (well, not really but you get the idea).

--
Florin Andrei
http://florin.myip.org/

jaharmi’s picture

I think there are probably some pretty valid comments that Drupal could be a better blogging system, but what attracts me to it is that it is a better CMS system, and eventually many bloggers would probably want to "grow up" to something like this. Having blogged on Manila since 1999 (and its predecessors before that), I can say that I want something with a rich CMS environment, and none of the "blogging" tools really fulfill that. Drupal and Manila are very similar in this respect -- they go farther.

On jseng's point #4:

I would actually like to see image upload as a story, and then be able to refer to the image via the Wiki-style links Drupal already uses for pages. This would bring it much more in line with the very handy Glossary/Shortcut feature of Manila (which allowed quick references to pages and other items, like pictures).

I could even see these references doing more: it would be great if I could specify a size (to shrink/enlarge the image, otherwise the size would be the default), change the justification (left/right/center), title, mouseover help/alt text, link, etc. right from the picture reference. This would be preferable, to me, than having to hand-code the HTML or even copy-paste it from another browser pop-up window.

So a picture link could be one like this, for the file "2004-07-31-001.jpg," scaled to a thumbnail no greater than 160 pixels on any size and linked to the original full-size image:

[2004-07-31-001|hw160|2004-07-31-001]

I know very little about Drupal right now but I've played with it in some free time for about a week, and possibilities like this (active development, unlike the stagnation in Manila) is exciting to me.

Jaharmi

javanaut’s picture

I've considered something like this for document management as well. The basic reference key for most content is the node id (or nid) as opposed to filename. The current image reference syntax (mentioned here) is good, but I would like to do something similar for the generic node case. How about a syntax like:

[node:12345,height=50,width=100,border=0]

When node 12345 is looked up, it is found to be of type 'image' and is rendered accordingly. The current image reference syntax:

[ image:12345,left,hspace,vspace,border ] (ignore spaces)

seems to work great. I think specifying parameter names would add flexibility to each node type's rendering engine. Consider an audio file:

[node:23456,autoplay=no,linktofile=yes]

When displaying this node in miniature mode or just displaying the teaser, then a thumbnail version of the node is displayed. There could be a default thumbnail for node types that are not visual.

The pitfalls would be potentially poor performance and yet another syntax to learn. Some of the reference code could be auto-generated (via javascript?), though, which would offset the odd syntax. The benefits would be allowing users to customize the layout of their nodes. With cacheing of rendered nodes turned on, I suspect that performance wouldn't be much of a problem either.

javanaut’s picture

Just updating this thread that I've implemented the above features with the attached_node module.

HTH

jseng’s picture

Let me show you one simple API:

metaWeblog.newPost
Description: Creates a new post, and optionally publishes it.

Parameters: String blogid, String username, String password, struct content, boolean publish

Return value: on success, String postid of new post; on failure, fault

Notes: the struct content can contain the following standard keys: title, for the title of the entry; description, for the body of the entry; and dateCreated, to set the created-on date of the entry. In addition, Movable Type's implementation allows you to pass in values for five other keys: int mt_allow_comments, the value for the allow_comments field; int mt_allow_pings, the value for the allow_pings field; String mt_convert_breaks, the value for the convert_breaks field; String mt_text_more, the value for the additional entry text; String mt_excerpt, the value for the excerpt field; String mt_keywords, the value for the keywords field; and array mt_tb_ping_urls, the list of TrackBack ping URLs for this entry. If specified, dateCreated should be in ISO.8601 format.

If you want to be compatible to blogging tool like ecto and zempt, the handling of mt_text_more, mtconvert_breaks and mt_excerpt is the bare mininum. Zempt wont even connect to Drupal right now.

cel4145’s picture

isn't zempt a blogging client specifically designed for MovableType, not blogging apps in general? so unless you have full support of MT's API, it would make sense that it might not work. but is it worth it to change Drupal's node architecture for blogs just to support a desktop blogging client?

jseng’s picture

thats a decision drupal core has to decide. if you dont think it is worth it, then so be it. but prepare to loose one bunch of user. and that is about >70% of the bloggers btw.

florin’s picture

Charlie, it's kinda odd to me to watch the discussion and agree with both parties. :-)
I agree with the comments that point out that any change, originating in D4B or elsewhere, must be made so that it integrates into Drupal according to the established rules.
But there's a pretty large kernel of truth in what James says. Like it or not, MT is pretty much a de-facto standard. A bit of effort to support certain MT-specific features might be useful for Drupal in the long term, as it would allow it to take advantage of tools built for MT. What's debatable is which particular features are more worthy of inclusion than other.

So, yeah, like the rabbi in the fable - "you too are right". :-)

--
Florin Andrei
http://florin.myip.org/

cel4145’s picture

well, i agree with you partially, too :) MT has emerged as "a" standard in the last 6 months to a year thanks to its increased market share (arguably there are other exsiting standards). whether it will continue to have additional influence as to blogging standards, i don't know. probably will depend somewhat on whether other blog apps take on larger market shares.

nevertheless, i've been following the drupal talk aggregator posts pretty closely now for about 6 months, so i've seen what many people have to say around the web about drupal in comparison to other apps. and i do believe that only a small percentage of the blogging population will care if Drupal has an excerpt/summary field, or whether Drupal works with zempt (which is a really new blogging client, btw). people tend to look at the range of features offered, so taking many of these enhancements, but not all, will still have a positive influence. but i would also guess that conversion modules, such as Seng's MT to Drupal, the install wizard and site profiling system (to ease installation and initial configuration), and the quality of documentation which reduces the learning curve for newbies will have a great impact on how many bloggers decide to switch to Drupal.

meanwhile, changing the node architecture for the blog module is a highly politicized issue. i would suggest reading up on the lengthy discussions which involved the change to using the break comment and automatic teaser generation during 2003. if you read through all of that, i think you'll realize that getting the development community to change node architecture to make it more like MT is like asking a governmental legislature to change a constitutional article for one small interested party. and this is how it should be. drupal is successful because it does not merely emulate what other apps are doing or make quick changes to do so. case in point for this is terminus1525 (which happens to be listed on Drupal talk at the moment). i guarantee that none of the blogging apps or nuke family cms's could generate a site like that, and it's few versions of Drupal back. and Drupal can do this exactly because it is not like those other apps :)

fx-1’s picture

.

jasonwhat’s picture

I want to use drupal4bloggers, but also need some of the features in the developers core (such as shop module). But I'd love to have the best of both worlds. For example, how can I easily make it so the blog url is www.mysite.com/username ? I need individual blogs so this is great for me.

I also have a php script that tells cpanel to automatically create a subdomain, if this could be integrated then users could be username.mysite.com just like the more popular group blog programs.

grantbow@civicspacelabs.org’s picture

mass_url.module by wazdog in the contrib CVS seems to work well, which uses a /blog/name arrangement.

jluster’s picture

I must say, I am opposed to artificially moving Drupal into the "blogging" corner. I am using an almost vanilla (some changes made myself) HEAD Drupal as my weblog, migrated from Movable Type (and before that from something home-grown), and don't see where Drupal isn't conducive to weblogging. Yes, Drupal does not have some of MTs paradigms and sometimes idiosyncracies, but I consider that a good thing rather than a problem.

The world doesn't need Yet Another Blogging App, we have enough of those, we need a stable and functioning CMS, and Drupal is the choice, here.

--
http://www.jluster.org

5dayapp’s picture

Though I'm not contributing code right now, I believe there's a line of thought people should run down. A module, a module alone, could handle most of the "blogging" issues related to Drupal. I found it rather annoying trying to figure out how to give each user in the commmunity their own blog URL, like domain.com/user/blog, etc.

But, Drupal is much more than a blog, and I'd like to see it progress far beyond any blogging sofware I've seen. So beware of the blogging purist pushing that agenda too far. You can acommidate their needs without hacking up the central system. I'm not suggesting anybody is trying to do that, just suggesting people consider the risks beforehand.

I'm enjoying Drupal. I can see myself spending some time contributing to this community.

-
Jason A. Nunnelley
There is One Truth

enkydu’s picture

I have a project that requires managing three blogs (and one e-commerce site) from one instance of a CMS and one db. So I'd like to find a great CMS (Drupal looks to be one, as does Mambo). I note that you've moved to Wordpress for your personal blog, which is smart. It has all the important blog features and then some. And you continue with Drupal for work where a CMS makes the most sense. That's also smart. What would you suggest for me?

sepeck’s picture

Please note that the Drupal for Bloggers package was based off Drupal 4.4 and contains some forks. Drupal can be used as a CMS and there is a development effort underway by CivicSpace do accomplish that. Assuming that by CMS you mean the same thing they do :)

As this thread is very old and conatins a lot of out dated information, please start a new thread with what you are looking for either in the General or the Pre-install (Is Drupal right for me) forums and some people would be very happy to provide posible solutions.

-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide