[support] I can't believe you can't add content from the command line...

Tue Jul 4 12:06:34 UTC 2006

On 7/4/06, dondi_2006 <dondi_2006 at libero.it> wrote:
>
> Sorry, my fault here. What I meant is that it doesn't make
> sense to have _one_ different "real/full editor" for
> every CMS, or every "rich text" use case one has to work
> with.
>
> This is what I find really absurd. It is like using a
> different mail client for every mailing list you subscribe.

Well, that's what the different APIs are supposed to give you.  And
note that Performancing provides the same interface and works with a
gaggle of different APIs which means it works with a pretty large
group of blog engines.  If you see necessary improvements in
Performancing, just let them know.  They're very interested in
improving it and they even run their site on Drupal :)

>
> > It would be handy to know more details about your situation:
>
> Right now I have some hundred opendocument files. Length is anything from 1 to 100 pages. structure is relatively simple, almost no tables or graphics. After importing those, I'll
> start to write new material regularly or import it from
> other external sources (my own mail
> archives, for example). How often I'll have to update
> which percentage of pages I don't really know now.
>
> So there are a lot of different inputs, but I could (I
> already am!) writing myself a different X -> HTML script.
> Is the next step, ie how to import that in Drupal from
> the command line, which is missing.

It's not missing, it's just done using a lot of different input
formats than you've got.

>
> > > What I see is that Drupal, Wordpress, and basically
> > > every blog/cms I know of is implicitly designed for
> > > author(s) who publish (very) short texts, only once
> > > in a while.
> >
> > Ok, I'll re-assert my point.  Imagine your requirements
> > in a multi publisher environment.
>
> I don't have to imagine that. This thread is about a website I am building, and will run, all by myself. But I am also a member of other multi-author portals ran exactly
>  like you say, done with Drupal, SPIP, Plone and others.
> Each site with different needs, each already existing (=I
> can't have it changed to drupal), each
> with its _own_ darned version of the text editing interface..., all mutilated, different buttons or names
> for the same task, different spelling checkers (= I have
> to re-define an acronym or custom term in ANY CMS I have
> to use, all while I did the same in OpenOffice years
> ago...)

It sounds like you want the ability to publish from OpenOffice.org to
these different blog engines.  Why not write that?

>
> > Multiple people editing multiple text files on
> > their client side and running scripts that directly
> > import them into the system.  That's what you want,
> > right?
>
> No, I have these admittedly weird and advanced needs only
> for a portal which I'll run myself, as said above.

And as you said further above

"I disagree here. I don't think the intended *number* of
authors matters at all.
What I see is that Drupal, Wordpress, and basically every
blog/cms I know of is implicitly designed for author(s)
who publish (very) short texts, only once in a while."

My contention is that your offline command line import tool would fail
miserably in a multi editor environment.  And I don't think you've
said anything to change my mind on that.

So are you talking about one author or a lot or...It's tough to find
the right solution when you keep changing the requirements/focus.  And
frankly, I think you've gotten all the help/advice that you can and
just need to continue writing the stuff.

> However, my co-authoring experience in those other portals
> I mentioned, while closer to your scenario, still sees
> several of us working OFF LINE for the same reason: the
> online interface, whatever the CMS is, sucks so badly
> that:
>
> * we exchange by email successive OpenOffice revisions
>   of anything longer than one page
> * when we agree on that, we flip a coin to find the
>   unlucky one which has to import it in the CMS GUI
> * generally, only _minor_ editing, like correcting typos
>   or updating single URLs, is done directly in the GUI.

"Sucks so badly" doesn't help us improve it.  You want full screen -
that can be done in your theme file or using some of the WYSIWYG
editors already.  You want spell checking that uses the same
dictionary file on all your sites.  That seems best implemented as a
browser extension so your dictionary is in the browser across the
sites and not installed on the server.  You want rich editing - done!
So, what features, more specifically, make it "suck".  Once we know,
someone (maybe you) can fix them.

>
> > Well, how do you control
> > versioning?  How do you control the individual
> > preferences ...How do you sync a local copy back with
> > the server copy (since there are multiple editors...)?
>
> In your scenario (~wikipedia, that is _looooooots_ of
> occasional authors who all publish occasionally, publish only one or a few (short) pages, and almost never interact
> with each other) I agree with you that the current CMSs
> do a more than decent job, and that other architectures
> probably wouldn't work.
>
> > I'm not sure I've ever heard/seen anyone do what you're
> talking about.
> >
> > people use all kinds of CMS for a wide variety of tasks
> > including very long and highly formatted documents that
> > get revised on a regular basis (have you seen the drupal
> > handbooks, for instance?).
>
> I have the drupal handbooks bookmarked and printed out. I
> am using them daily these days. I consider their quality
> (as one ORGANIC, COHERENT corpus of usefully interrelated information (*)) pretty low, and a good example of what
> I am saying: even if the single authors are good and committed, they are limited from their tools: the current generation of CMSs is not designed
> for (what I consider) serious, continuous work.

and your asterisk:
> * regardless of formatting, and I'm not even referring to
> the single pages which often are quite good

While they have their problems, the Drupal handbooks are always
getting better and always welcoming new writers.  I don't see how the
handbooks show any sort of systemic deficiency - sure, they have
problems, but I don' t think those problems would be solved if peopled
had a command line import or an OpenOffice.org "Save to BloggerAPI"
option.  Again, if you see that then please state it specifically so
it can be fixed.

> I don't remember if I already said it, but I am sincerely
> enjoying this discussion, it's not my intention to troll,
> and I don't mean to whine or make a joke of anybody's hard work.
>
> I am just saying that the quality and usefulness of Drupal
> and other tools, while very great, is not exactly what is commonly perceived: I like what I am learning through
> this discussion, which is really helping me to understand
> several sw design concepts.

Well, the current CMS input mechanisms are exactly what I perceived.
I think you need some citations to blog posts beyond your own point of
view to be able to say that CMS input mechanisms is weaker than
commonly perceived.

Regards,
Greg

-- 
Greg Knaddison | Growing Venture Solutions
Denver, CO | http://growingventuresolutions.com
Technology Solutions for Communities, Individuals, and Small Businesses