233996 - Allow arbitrary publishing commands, at least SSH

Status: RESOLVED WONTFIX

(SeaMonkey :: Composer, enhancement, P4)

Description

[August Mayer]

User-Agent:       
Build Identifier: 

Web pages can be published in various ways. FTP is becoming out-of-date, because
of its security problems (plaintext password transmission); instead, SSH / SCP
becomes more common. But it would be generally nice if the user could specify a
command with parameters to execute on publishing; this would give the user
maximum flexibility.

Reproducible: Always
Steps to Reproduce:
1. Start Mozilla Composer.
2. Choose Edit -> Publish Site Settings...
3. An input field with the title "Publishing command (optional)" should be
available.




It would also be possible to add the capability to specify an ssh:// URL, but
I'd prefer a general solution that allows quick solutions. For example,
sometimes it is necessary to publish to the local system (e.g. if a web server
is running locally); this could also be solved by specifying a simple cp command.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

>sometimes it is necessary to publish to the local system (e.g. if a web server
>is running locally); this could also be solved by specifying a simple cp command.

or by specifying a file: url that should work today.

Comment 2

[August Mayer]

(In reply to comment #1)
> >sometimes it is necessary to publish to the local system (e.g. if a web server
> >is running locally); this could also be solved by specifying a simple cp command.
> 
> or by specifying a file: url that should work today.

Nice feature, but they did a really good job to hide it. This should be in the
documentation!!! (It only speaks of ftp:// and http:// URLs, and that one should
contact the system administrator, for whom even less documentation exists - any?)

Also, if I enter a path like /var/www/html into this field, it gets converted to
ftp://var/www/html, and that is a real bug.

Comment 3

[timeless]

arbitrary is the only thing keeping this bug from being resolved against bug
231457. but arbitrary is also less likely to be implemented. post a patch.

Comment 4

[August Mayer]

(In reply to comment #3)
> arbitrary is the only thing keeping this bug from being resolved against bug
> 231457. but arbitrary is also less likely to be implemented. post a patch.

This is true, and it will be sufficient for my use. However, the idea to
generalize this feature is still there. Either this bug could be left in the
database for later consideration, or closed with WONTFIX.

No time available for hacking into mozilla and submitting patch, sorry.

Comment 5

[Mark Stier]

My suggestion:

add a table to the mozilla editor's configuration interface. Each line of the
table contains 4 fields:

1.) Published location (parent directory)
2.) optional regular expression
3.) Source location (where the raw and unprocessed file is being stored)
4.) Target location (where to write the modified file to)

The first two fields are being used to decide which source and target locations
to use.

Why regular expression? CGI scripts are often stored at different locations but
within the same URL. 

Field 3 may contain all protocols that mozilla can handle to get files.

Field 4 may contain all protocols that mozilla can handle to write files.

Fields 3 and 4 may additionally contain commands to be executed locally. That
way Mozilla does not necessarily support SSH. Installing a ssh client would be
enough.

My personal way to do modifications to my website, is to change the local files
and then run rsync manually. Would be nice if mozilla could decide on its own
what to do.

One very neat aspect of that solution is that one could even edit scripts or SSIs.

Comment 6

[August Mayer]

(In reply to comment #5)

I think that's quite complicated, both ui-wise and in the implementation. Why
not just add a "Publishing command" field to the interface, as I initially
suggested, and use a batch script that handle the rest? :)

> My suggestion:
> 
> add a table to the mozilla editor's configuration interface. Each line of the
> table contains 4 fields:
> 
> 1.) Published location (parent directory)
> 2.) optional regular expression
> 3.) Source location (where the raw and unprocessed file is being stored)
> 4.) Target location (where to write the modified file to)

Comment 7

[Mark Stier]

(In reply to comment #6)
> (In reply to comment #5)
> 
> I think that's quite complicated, both ui-wise and in the implementation. Why
> not just add a "Publishing command" field to the interface, as I initially
> suggested, and use a batch script that handle the rest? :)

Do You really think that inserting a table into the UI, doing string comparisons
and checking if a protocol is supported is complicated? If that is true, we
should rather think about simplifying mozilla's internal code structure :-)).

Comment 8

[timeless]

inserting a table into the ui is easy.

having a user who will not be confounded by such a table will be rare.

creating a table which doesn't confound the user would be hard.

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #8)

> inserting a table into the ui is easy.
> 
> having a user who will not be confounded by such a table will be rare.
> 
> creating a table which doesn't confound the user would be hard.

Exactly. I remind you that most people have never heard of ssh or sftp,
including many SW engineers. Only geeks like ourselves know about it.
With my module owner hat on, this is a WONTFIX.

Comment 10

[August Mayer]

(In reply to comment #9)
> including many SW engineers. Only geeks like ourselves know about it.
> With my module owner hat on, this is a WONTFIX.

I find the current solution too inflexible. However, I would personally be
satisfied with a solution to bug 179456, too.

Still, I maintain that my original idea would be nice. Maybe I'll find some time
to hack on this.

Comment 11

[Mark Stier]

(In reply to comment #8)
> inserting a table into the ui is easy.
> 
> having a user who will not be confounded by such a table will be rare.
> 
> creating a table which doesn't confound the user would be hard.

The usual user uses IE and not Mozilla. And if he uses Mozilla, then he usually
does not know of the preferences dialog at all (I know some of them, hehe). Show
the advanced settings only if the user checks a specific checkbox. That would
allow us to target a larger user base. Aren't the advanced features what makes
Mozilla better than comparable products? I'm interested in an open-source
browser because I hope that it will have much more "geeky" features somewhen ...
even if I have to implement them myself :).

Last but not least: the 1.7rc1 html editor is pretty unstable.