By airor on
The biggest issue I have with developing pages in drupal, is that every subsequent page I want to create using the create pages method, must be done with create page and the interface is really painful when it comes to development.
It would be significantly more usable, if I could simply just upload a file or something of that nature instead of copying and pasting code into that little textarea interface. Perhaps I am missing something, but why would anyone do all their web page development inside a textarea?
That just seems oddly painful.
Comments
Blogapi or a textarea plugin
You might want to consider editing your pages through a blog software using the core blogapi module, or using a plugin module that provides WYSIWYG, like the tinymce or htmlarea modules.
Alternately, of course, edit your page first and then cut and past it into the node/add/page or whatever textarea.
Total Agreement...and some ideas
Airor, I very much agree with you.
In fact, I think this problem is endemic to almost all web sites: text areas are too small.
I have no idea why HTML preparers feel the need to limit the size of form boxes. It's as if we've never gotten past the 640x480 days of the early 1990's.
Screens are larger, web page views can be larger, and certainly TEXT SIZE and TEXT AREAS can be larger. (So many web sites I visit display at 9 points, and I have no idea why...no one reads text on a computer screen at 9 points.)
As for Drupal, and other CMS'es as well, there is no real conception that "this CMS" lives with other web content. There is a separation of the content in a database and all other items in the file system. This shoud not be. The over-reliance on databases to hold bits of HTML is very odd to me. It's nice, of course, for the user who stumbles onto a site and wants to post some comment...they are not interacting with the file system's objects. However, the site creator and maintainer should be able to move information into and out of the database, especially _into_ the database, with a source that could be local (on the server) and already on the file system.
For example, in more clear terms, consider the notion of "uploading a file". That's pretty ubiquitous and all CMS tools have such a feature in some form. But what about just "pointing to" a file already on the server?
Especially when first setting up a site, during a transition from fixed-file content (HTML pages, PHP pages, etc.) to a CMS with a database engine backend, you would not really need to "upload" things again (especially images and binary files to download). But, there is no way to get this information (the file's location) (or even an HTML file's contents) into the database.
Now, there are some scripts for Drupal that purportedly allow the import of a static HTML site. These have limitations, especially related to the original (source) file's format (DOCTYPE). The scripts rely on XSL stylesheets and therefore need very well structured static HTML files before the importing will work.
But...
This doesn't really help your issue -- and the issue that many face: why are text areas so small? and how can I get my current HTML content into Drupal?
Well, text areas can be enhanced with some JS, like the Drupal "height-changeable text areas" that some are griping about now (I like them, but I wish the width could be changed too.)
Frankly, tinyMCE and other "wysiwyg" JS editors are just horrible. (I can not believe we've gotten increased desktop power in our computers in recent years, and now everyone thinks it would be swell to toss off tasks to an internet connection...slow and backward.)
What I would recommend as a work-around (with all the time that implies ;) is that you consider using PHP tags in Drupal to "insert" your older content into the page display, but specifically into the database (or you can do that later). This may take a conversion process, such as duplicating your entire web directory and contents (as a backup) and editing those files to be sans-HTML doctype and headers and such. Strip out everything that is not inside the
<body>...</body>tags (and strip the body tags, too) and re-save these "chunks" (very technical term) without an ".html" or ".php" extenion. A file you had that might have been called "sunnyoutlook.html" will now be "sunnyoutlook.txt" [I keep all my files in a single directory, and all named with ".txt" extension.]Then, you can simply call a page by using a static include call:
<?php include "myconvertedfiles/sunnyoutlook.txt"; ?>Or better, you pass along a variable, say
$include_page_name = "sunnyoutlook";and then you just need:<?php include "myconvertedfiles/{$include_page_name}.txt"; ?>...and you're cooking with gas.
This is no real alternative to the issues at hand (well, small form widgets are just poor design and that could be changed, but no one seems to worry with it and for some reason folks go about as if they are happy editing HTML in small boxes and over the web), but at least this is a way that you can mitigate the headaches of the transition to Drupal (which is worht it!) -- it can buy you some time, that is, which is the same as money, they say. So, it can buy you money. ;)
Then, as you can, you either move the file "chunks" into the database, or you can simply continue life under your new Super-Include system.
I prefer to edit and create HTML on my own computer, with my own tools, and with my own comptuer's speed (and spell checking and AppleScript and all the other tools that I use to write and work and make things.) This way, I can save, edit, store, archive and all that (which I can not do with a Drupal-driven database site, or any other CMS software for that matter...a flaw in all, I think) Then, when I'm ready, I simply upload my perfected "chunks" of HTML+PHP to whatever directory I want (again, I keep all HTML chunks in one place).
The future of CMS tools (if people will ever stop making new ones) is to integrate them with our local desktop, so that we can edit posts (like this one) in whatever tools we want (I'm in BBEdit right now, did you notice?...no, you didn't, and why should you?) and with whatever software like, and then we can simply "insert" that content to some form field.
But, alas, folks have fallen in love with the idea of not using their very powerful software tools on their local machine and using a web browser to do everything. A sad state of affairs, arguably.
HTH, and best of luck with the small text areas.
--
http://AccidentalTechie.org
A tool to import html content
Take a look at http://drupal.org/node/55575
Although aimed at Macromedia Contribute content, it could work with pretty much any html content. The documentation doesn't include info about the latest changes. The module now imports the content into a node and stores it in the db. It is under development, and has a few bugs, but it's worth a look. It's the simplest of the html importers that I've seen and I've tried them all.
I didn´t get it
I think you guys may have a point but i really don´t get it.
Firstly, I always believed that one of the major features of a CMS is to allow non-tech people (eg. blog users) to publish content to the internet without the need of programing or designing skills (eg. Html, CSS, PHP, Mysql). That said, I believe textareas are supposed to be used as "text" input, not code. One of the jobs of the CMS is to allow content creators to worry about content (like writing text), and coders to worry about code and web designers to worry about web design. If you have to edit all of your pages on a html editor you´re problaby doing something wrong or maybe you don´t really need a CMS. It would be nice if you explained what you´re doing in detail.
Now about monitor sizes, I believe most people in Brazil still use 800x600 resolution. That may be the case on other places since many I´ve seen many sites that are made to fit exactly on an 800x600 configuration (www.ibm.com comes to my mind now). I use a 1208x1024 configuration and pretty much everything on the web looks pretty out of proportion to me.
-- Alexandre Ataide
I don't see the target
I don't see the target audience then. If I wasn't tech savvy, I wouldn't be using drupal. Aside from the other options that are far better for non-tech savvy people, the installation process alone would be prohibitive to a non tech-savvy person.
I love the power drupal provides. But I'd like is for the abilty to point to files / edit using my own editor. I assume all pages are stored in the database. If they were stored on the filesystem and I could edit them in that manner (or give permissions to other users to write to that directory), drupal would be enabling me to take advantage of all the tools I could use on a typical unix box! Which would make me very happy.
Textarea editing for writing pages is annoying to say the least and for a CMS that's supposed to be capable of community development, the permissions system is non-existant (makes me cry!)
Unfortunately, I don't know of anything better. That drupal insists on existing entirely self contained I guess is a nice goal, but why reinvent the wheel for everything eh?
>>>I don't see the target
>>>I don't see the target audience then. If I wasn't tech savvy, I wouldn't be using drupal. Aside from the other options that are far better for non-tech savvy people, the installation process alone would be prohibitive to a non tech-savvy person.<<<<
I don't think he means the admin so much as the end user. The end user wants to do things in a manner that is easy to use and easy to understand. HTML is not eacy to use and easy to understand for 3/4 of the internet. The most they know is bold or italics, and nothing about linking images or websites. It would be better for the end user to see a nice interface so they can work faster and get back to the real world.
I guess the real problem is
I guess the real problem is that while drupal is great for posting blogs.. there are better things for posting blogs, which means a large portion of the intent for using drupal is also along the CMS side, which invovles creating pages, which puzzles me why there'd be such a restrictive / clumy interface for editng pages.
It's like designing a top of the line sports car, but requiring the owner to open up the engine and start it by hand!
It's a decent CMS, but development si greatly hindered by the necessity to do everything in an htmlarea.
Anyway, thanks for the tips on the includes, I had been doing that a little bit, but tedious it is yes.