- Development - lists.drupal.org

[drupal-devel] vanilla: this is how forum software should look / work
by Kristjan Jansen 24 Jul '05

24 Jul '05

http://getvanilla.com/ http://lussumo.com/community/ Comparing their approach to Drupal's we do not fare bad at all. Some tiny details I like (to rip from them ;): Not logged in: * Overall look. yes, perhaps too Typepad but nice and smooth netherless (perhaps even too low-contrast, I have missed many vital UI elements) * "edited" mark next to a comment * Informative login / register dialogs Logged in: http://lussumo.com/community/signin.php guest:guest * switchable small / big textarea (but ihmo it should work vice versa, small -> big) * ajax-based (un)bookmarking * ajax-based (un)blocking topics (taxonomy) * navigation history block * search history block

1 0

[drupal-devel] [feature] add inline functionaliy to uploads
by Bèr Kessels 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/26288 Post a follow up: http://drupal.org/project/comments/add/26288 Project: Drupal Version: cvs Component: upload.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Thank you for your thoughts Tdobbes. As for the "moving things in and out of nodeapi" This was necessary, because otherwise the patch would have made the code even more unreadable. I agree with you on this point, but I simply had to clean it up a little, in order to be able to work in it. As it stands now, it is simply not possible to make this a separate module. We cannot hook into the files table. In a next stage, I might work out some hook for that table. But first things first. Can Dries or Steven please comment on his. I want to know If i should bother spending this enormous amount of time on commenting and debating this issue. If the chances are small this is accepted, Ill just drop it This ridiculous long thread reminds me again why I try to avoid making patches for core. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:03:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline.patch (19.05 KB) One of the most often asked features is proper inlnie handling of files. Look at the amount of solutions, the popularity of image_assist, and the amount of peolpe dowloading image.module! That alone should be enough proof that Drupal lacks proper inline image support. This patch adds that to core. In fact, it does little more then appending a link of img tag to the body or the teaser. Off course that is configurable per file. Next to the [] list checkbox, this patch adds an [] inline checkbox. Simplicity is the foundation of this patch. I want no stles for inline editing, no fancy html wrappers, no tokens, just $node->body or teaser appended with a small html string. Another small themable funtion is introduced, (hey, you cannot expect me to develop something without adding more power for themers, now, can you? ;) ), that allows people to theme the string that is appended to the body or the teaser. Oh, and also note hat the biggest part of this patch is some cleaning I had to do in order to be able to develop properly. I dont like Ifs inside cases in foreaches inside swiches. in other words: nodeapi now calls functions instead of executing code directly. ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:25 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot.png (26.68 KB) here is how the form now looks ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:58 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot3.png (30.53 KB) and this is an example of inlined images and a .doc file. ------------------------------------------------------------------------ Sun, 03 Jul 2005 20:44:00 +0000 : sepeck changing to patch per request from berkes ------------------------------------------------------------------------ Tue, 05 Jul 2005 07:46:13 +0000 : Kobus This gets a +1 from me in principle, however, the [inline:xx] tag with inline.module gives you greater freedom as to where the inline image must be displayed. If you can add this functionality (I haven't checked the code, I don't know if it is in there) it would be a great addition for Core. This same strategy can be used for inline blocks, I am sure. Regards, Kobus ------------------------------------------------------------------------ Tue, 05 Jul 2005 08:57:50 +0000 : Bèr Kessels there are a couple of reasons why i did not include the [inline] tags. * I aimed for extreme simplicity: a checkbox shows an image inline: its up to the theme where it appears (if one does not like it before/above the body and teaser.). Simplicity was the main goal. * We don't have any tokens in core. And we should not have them. * Tokens are a very bad substitute for a good interface. They give less power then plain HTLM. Are much worst documented then HTML, but in the mean time, they are still as hard to learn as HTML. (Yes, I know people _think_ they are easier, but there _is_ not difference between [ ] and , only that its a different ascii char. So, no. I don't allow any placement of the image. I leave that that for dedicated modules, or the themer to decide. ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:34:06 +0000 : Kobus So you will provide an API to do this? For example, with perhaps minor modifications, the inline.module will be able to display these files? In that case I am happy. If not, then I can't give my support to this patch (as if that matters...). A themer can't do this task as inline images (and blocks for that matter) is too dynamic for theming; it can be placed anywhere in a node where the user pleases. This means for me that there should be a module for this, such as inline module that allows you to define [inline:xx] tags. If your module emits an array of uploaded files (such as upload.module), inline.module can be, with minor changes, adapted to show these files inline. To show you what I mean with the content is too dynamic for a themer to perform this task, look at this screenshot related to inline blocks (inline images can follow the same pattern): http://drupal.org/files/issues/regions---possibility-3.png ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:26:15 +0000 : Bèr Kessels Kobus, We are dealing with different issues here: You want a method to place images, files or so anywhere in the post. That is fine, but certainly NOT addressed in the patch! I made patch that *only* adds marked files to the body. its really nothing more then <?php $node->body = $filestring . $node->body ?> No APIS, no, dynamic tokens, no filters, nothing. However, what I meant with themers, is that there now is a theme_upload_inline available, so you can theme the abovementioned $filestring. On top of that $node->files[FILEID]->inline is TRUE if a file is flagged for inline. So in node.tpl.php, or wherever you want to theme a node, you can print nice images inline, when that flag is set. And about the comment that a themer cant do this: Simply not true. On most sites images are always placed in the same places. REally, even the sites see which use img_assist or inline, use them to place the images on the exact same places in every node. People /think/ they want the power to place images anywhere, but they hardly ever use that power. Just look at all the big news/publishing sites out there (BBC, CNN, BoigBoing, r even freshmeat) images are all placed acc. to the theme. They are not placed in random places by authors. So if you are one of the few that still want that power, there aer mots of power tools like inline module or img_assist. We should offer a good default, one that is simple. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:41:34 +0000 : Gerhard Killesreiter I fully agree that tags are evil. Kobus: You can always look for tags in $node->body in your theme's node function. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:50:52 +0000 : stefan nagtegaal Ber, the theme-function in your code looks like: <?php +/** + * Theme function for rendering of inline images + * @param $file a file object. + * @param $image a Boolean, indicating whether an img tag (TRUE) or an anchor tag (FALSE) should be used. + * @ingroup themable + */ +function theme_upload_inline($file, $image) { + if ($image) { + return '<img src="'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'" alt="'. check_plain($file->filename) .'" class="upload inline">'; + } + else { + return ''. check_plain($file->filename) .' [1]'; + } + +} ?> After looking at your code it's not clear to me when $image is TRUE or FALSE, can you elaborate on me please? [1] http://drupal.org/'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'\" class=\"upload inline ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:06:39 +0000 : Bèr Kessels The function calling the theme function should decide whether its an image. IMO that is far too hardcore code for a themer ;) <?php $image = ereg('^(image/)', $file->filemime); ?> inside _upload_inline() does the trick. I did find one issue, though, with svgs, which are image/svg so maybe we should limit this to really only inline jpg, png, and gif, by extension? But I am no fan of determining files by extension, and IMO getimgsize is too heavy; ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:13:52 +0000 : stefan nagtegaal Can't you make use of PHP's <?php image_type_to_mime_type(); ?> or <?php image_type_to_extension(); ?> ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:45:43 +0000 : Kobus Well, if not in the patch, I need inline functionality one way or another. inline.module works perfectly with the current upload.module to fulfill my needs, and if there is a way where someone can extend your proposed upload.module, that would get my +1, otherwise I will just remain neutral about this issue. inline.module makes use of $node->files and displays that image. If your patch still uses $node->files, then this is a non-issue. In other words, if I can, with inline.module, or with minor modifications to inline.module still show files inline, I am +1 for this. As for the themability question... I still disagree. You say "Simply not true. On most sites images are always placed in the same places." That is ONLY true because they have NO alternatives. Means the content is in the same places, because they have no other places to put them. I have made tens of static sites where the content does not resemble a fixed pattern or structure. For me, free-flow layout is my expression of my creativity. This is why I still even BOTHER with static sites; when Drupal don't do what I want it to do. If Drupal could do inline display of content properly, I'd never even build another static site. It is a great mistake people make (including myself), and that is they design the site before ANY content is available, and this happens a lot in static sites. But in dynamic sites, you have far less control over this, unless you have a VERY clean structure with limited information that can be added, and only a few people posting content. If you can have your content before you start the design, you will have a better fit. I can't see how you can anticipate every possible posting posted on your site if you have a diversity of users. Especially not if you're using a site such as an designer's showcase site where your creativity is shown by your web sites. Possible, but not easy. If I claim that I have "unique, fresh designs" I can certainly NOT give them a "box-like" site with "left and right side bars only". That's why I need inline content, this includes images AND boxes. Gerhard: Your concern about tags is answered as well above, if I am not mistaken. The patch need not provide the tags, but should provide for someone to develop a module that provide the filters or tags. To summarize: I don't need your patch to do the inline images. I just need your patch to be able to allow someone else to develop a module that can display inline files. Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 09:56:38 +0000 : Bèr Kessels okay, so for all clarity, let me sumarise: * this patch introduces a chackbox "inline". If checked, the file will show up inline. IT will be appended to the teaser and the body. * this patch does *not* allow one to place images of files in a userdefined place in the body. * this patch does *not* do any resizing nor any thumbnailing. * This patch is meant to be simple, clear and transparant. No tokens, no javascript, no nothing. ------------------------------------------------------------------------ Mon, 18 Jul 2005 11:21:54 +0000 : Kobus Then I can't see how this patch could replace the existing upload.module, which allows you to use inline.module to place images inline. I therefore withdraw my +1 and go -1 on this (not that it matters, I believe). I think you didn't properly read my previous message. I said I don't need your patch to do all this, but I can't live without the functionality currently provided by the upload.module and inline.module combination. I agree that your patch don't need to have that functionality, but if your patch takes away this functionality, in other words, I can't (by hook or by crook) manage what I need to do, my vote is -1. Regards, Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:58:34 +0000 : Bèr Kessels Kobus, And all the others looking fofr advanced inline systems: please do not -1 this. It will hep inline module a lot too. allthough not yet in this patch, but can you imagine a perission system for inline module, that comes for free? Or a core system, that makes inline module ten times smaller? it is this path! so, please, if it is not /exactly/ what you are looking for, at least look at the advantages for Joe Average, and even for the possibilties for your favorite inline-module. even imag_assist will gain an anomous usability impcact when usiong this module, for it can then finally use the upload module in full scale. Ber ------------------------------------------------------------------------ Sat, 23 Jul 2005 18:59:10 +0000 : Bèr Kessels Sohodjo jim: " I hope it matters. A big -1 on enforcing over-simplification at the expense of important and existing functionality. If automatic, uncontrollable placement of images becomes the standard, it will mean fewer not more image-rich Drupal sites as site owners/developers get complaints about "Why can't I control my images!" I _strongly_ encourage Ber to provide a "have it both ways" solution. Why not have an admin configuration setting for "allow inline tags" with default off. Change it to on and you get an additional upload checkbox for 'inline at tag' to accommodate the current functionality of the inline module while simultaneously allowing for default placement. " NOOO. people; please; look at the PATCH. Again: and hopefully last time: Simplicity. This patch does NOT replace ANYTHING inline module or img_assist wants to do. This patch hands better data to such modules. It hands a variable over to these modules, $node->file[FID]->inline, which tells these sorts of modules if people wnat that file to appear inline. AND it CAN (by default will) render a file in the most simple way inline. So really, if you want to -1 this patch, fine. But do not -1 it, because it does too little IYO. It still allows MUCH more than what you can do no, without that patch! And any solution, for core, that allows advanced handling of inline images will either require an enourmous amount of work, or it will simply no get in. So, unless you come up with a good core-worthy patch, this is still a big leap forward from what we have now. ------------------------------------------------------------------------ Sat, 23 Jul 2005 19:01:51 +0000 : Bèr Kessels :$ this is an attempt to fix the borken HML in the previous follow up. ------------------------------------------------------------------------ Sun, 24 Jul 2005 04:07:34 +0000 : TDobes Please don't combine unrelated changes together in the same patch. Moving stuff in/out of the _nodeapi hook has absolutely nothing to do with the patch and makes it much harder to read through the patch and see what it's actually doing. I'd appreciate it if you could separate the changes made here which are really relevant and move the other changes into another issue. Also: You change form_group_collapsible(t('File attachments') to form_group_collapsible(t('File Attachments'). A quick glance at some other core code seems to indicate that we've standardized on capitalizing only the first word in multi-word group titles. As for the functionality itself, I don't think this belongs in upload.module. It would be useful to have the functionality in core, but as a separate module which can be switched on and off. (upload_inline.module or something like that) If a site were set up using an inlining system from contrib and the functionality you're proposing could not be switched off, it would be extremely confusing to users that there are two different ways of inlining images. A minor comment: I'm not so sure whether the results of this patch, when inlining non-image attachments, will be the one users expect. A non-web-savvy person may expect his/her Word document (for instance) to appear inline with the node when they click "inline" -- just like their images do. I'd suggest that we limit inlining to images only. I'm not as adamant about this as the other issues, so I could be convinced otherwise if others disagree.

1 0

[drupal-devel] [task] Drupal Install System
by Bèr Kessels 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/5496 Post a follow up: http://drupal.org/project/comments/add/5496 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: Bèr Kessels Status: patch Stefan, the tarball contains over 20 new files. A patch would be a horror in this case. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Thu, 29 Jan 2004 09:10:25 +0000 : adrian I am in the process of developing a new Install API for the drupal core, which will allow a completely web based install / set up process, as well as allow contributed modules to integrate more directly into this system. A more detailed description of the system is available in this thread. This task has been created to place each of the successive patches in the patch queue. ------------------------------------------------------------------------ Thu, 29 Jan 2004 09:20:48 +0000 : adrian Attachment: http://drupal.org/files/issues/install_api_first_level.patch (6.42 KB) Kjartan correctly identified one of the problems in creating a unified install system. There's a lot of code that gets run by simply including the core files (bootstrap.inc, database.inc, session.inc and common.inc). A lot of this code relies upon the database connection going off without a hitch, like for instance the current system variables, themes and session code. To work around this i created a new drupal_init() function, which needs to be called when you want the system to initialize. drupal_init has a 'db_init' argument, which allows you to bypass the loading of all the database related code with a simple flag. install.php needs to run drupal core, while ignoring any database connections .. until atleast the point where the configuration settings for the database are entered, and confirmed to work. There is a new function created called 'database_connected()' , which returns a boolean true only if the database both connected and the table was selected successfully. This patch does not have a suitable error message for index.php upon not being able to make a database connection ,but that message should very likely be discussed and finalized. In the next level of the patch I will introduce the major changes, or rather additions. I haven't modified any existing files beyond the ones in this patch (at this time). ------------------------------------------------------------------------ Thu, 29 Jan 2004 12:24:15 +0000 : Kjartan This patch has some serious flaws though. <?php include_once "includes/bootstrap.inc"; -drupal_page_header(); include_once "includes/common.inc"; ?> By removing the drupal_page_header() you break the whole point of bootstrap as the common.inc stuff is included when its not necessary. It needs some more thought. Maybe you should take the time to make a workflow of the current Drupal init process before modifying it. Also the naming of constants, I would prefer calling them DATABASE_ATTEMPT as it makes it easier to tell them appart. ------------------------------------------------------------------------ Mon, 09 Feb 2004 20:18:35 +0000 : adrian I have reworked the patch into a very minimal set of requirements. To prevent the .inc files from running any code when you don't want them to , you 'define' a constant called 'DRUPAL_NO_INIT' before including bootstrap.inc. This relatively small patch is required for the install stuff to work. ------------------------------------------------------------------------ Mon, 09 Feb 2004 20:22:35 +0000 : adrian Attachment: http://drupal.org/files/issues/drupal_no_init_flag.patch (3.88 KB) i'll even attach it this time. ------------------------------------------------------------------------ Mon, 09 Feb 2004 20:48:06 +0000 : adrian Attachment: http://drupal.org/files/issues/database_init_return.patch (1.96 KB) The following patch is a modification to the includes/database*.inc set of files, to make db_connect return a boolean value depending on wether the connection was successfully made. I have changed database.inc to die() upon connection error with the message "Database Connection Unsuccessful". Cleaning up that message and placing a help page might be a good idea from an user experience point of view. This patch is required for the install system, in that it needs to test wether it has made a successfull database connection before it allows you to actually install the schema. ------------------------------------------------------------------------ Tue, 10 Feb 2004 01:15:14 +0000 : adrian Attachment: http://drupal.org/files/issues/install_system_alpha.tar.bz2 (11.59 KB) This is an alpha version of the new install API code. It is completely capable of installing the drupal core system without requiring any interaction with the database side. There are currently 5 configuration screens , but the API is sound for us to add / remove / change these screens as we need. In it's current state, it isn't capable of updating the base system, however the backend stubs exist, and have been tested. In the push to get the install process running smoothly i simply disabled the update interface. The previous 2 patches on this node need to be applied, but have been combined into install_system_alpha.patch which is included in this distribution. The rest of the files are new , and should not interfere with the drupal core at all. They are includes/install.inc ... the file that hosts the install api. install.php ... the front end script that initializes the install api (a total of 5 lines) install/system.install ... the install module for the core. It contains the bulk of code from update.php, and all the configuration information needed to successfully install the core. In the future , the install api will be able to easily install any contrib module through the modulename.install file that will hopefully become well supported. Note: I need to update the postgres compatibility in this .install file, and as such only mysql is fully tested now. I have posted some screenshots at my site ------------------------------------------------------------------------ Tue, 10 Feb 2004 18:22:02 +0000 : adrian Unconed just pointed out there is a conflict with windows installations in that there can not be an 'INSTALL' file and an 'install' directory (which contains the system.install currently) He suggested that we rename the README and INSTALL files to README.txt and INSTALL.txt. I personally move that we store the .install files within the modules directory , as in the future installing a contributed module should be as simple as dropping the module directory (containing .install , .module and whichever external files) into modules/ , and then installing the module within drupal. ------------------------------------------------------------------------ Thu, 12 Feb 2004 05:10:16 +0000 : moshe weitzman I played around with the patch, and successfully installed a new Drupal instance on the fitst try. Nice work, Adrian! I reviewed the code too, and found it quite Drupalish and satsfactory. Here are some notes from my install: - On the configuration file page, I selected from the radio button options a file which was not conf.php and thus did not exist. I strugged with the 'file is not writeable' error for a while until I realized that you expected me to create the file and then the installer would edit it ... in general, this page is a pretty complex introduction into drupal. I suggest simply assuming 'conf.php' here. I haven't thought about this much though. - Similar to above, I figured Drupal would create a database for me. Not so, I had to create it and then Drupal takes over. Some simple help text adddresses this point. - Use form_password() or similar when requesting a database password - The default $base_url was missing a slall for me. It said 'http://medrinstall' instead of 'http://me/drinstall' - After completing the DB install, there is no page telling you what to do next. A link to the home page is all thats needed IMO. -The site_name chosen during the install was not saved in the 'variable' table. - When you return to install.php some time later, you have no indication what a working site already exists. Not sure thats the right thing to do. Not a big deal though. P.S. Adrians suggestion to store the .install files in module specific subdirs under modules makes sense to me. Thus system.install would move to modules/system/system.install ------------------------------------------------------------------------ Fri, 13 Feb 2004 04:04:29 +0000 : skip I had to set up a pMachine blog yesterday for a client. I have to say... it was the easiest install process I've ever gone through (CMS-wise). Very user friendly. Lots of feedback to the user. If you haven't seen it before, you should check it out for ideas. ------------------------------------------------------------------------ Wed, 18 Feb 2004 05:26:10 +0000 : adrian Attachment: http://drupal.org/files/issues/install_phase2.tar.bz2 (12.96 KB) So I have spent far too much time over the last few weeks battling with this install system. My current results are in this here tarball. This time I am even less sure of it fully working in all cases, than last time. With this release I added extensive error checking to the install process, finished MOST of what is needed for the update process , but most importantly... it is a lot more secure than previously, and is specifically built to allow people to host their multiple drupal installs from just a single root. I have handled this by adding a global variable to the config file (allow_override_config) , which is checked by the install script before a new configuration file is made that would override the currently active one. There are three settings to this : 'no' , 'any' and 'auth'. I feel auth is generally the best option, as it requires anyone trying to override a working configuration file to enter the username and password for the site he is trying to override. Added checking also exists for the minimum requirements of running a drupal system (the tests probably need to be fleshed out), aswell as refusing to install a database dump into a db_url/db_prefix which seems to have a valid site installed. When a working configuration is detected on startup , the default action is to require the administrator user of the site to log in. This is for security reasons. The install script has lots of code that stops it from ever overwriting any config file that has already been created, but as I said .. it allows for the creation of a config file that will be parsed before the current valid install, but only with the express permission of that config. Config files have been moved to './conf/' , and the default config has been renamed to 'conf/default.php'. I have split install.inc into install.inc and install.module, as there was a lot of interface code specifically for the update/install sequence (and it is best available for reuse .. so i didnt wanna put it in install.php). This has an unrelated quirk for xtemplate .. I left it in the patch because for some reason I was unable to get a working default theme because xtemplate refused to populate the 'path' template variable. I also have an extensive 'gallery' of the new changes if you just want to see what it looks like. Directions for use : untar in a drupal cvs tree , and 'patch -p0 < install_alpha_2.patch' go to http://mysite/install.php ... previous configs in includes/ will be ignored for extra fun , create a hostname entry to sitea.siteb.sitec.sited.mysite , and watch the install script pick up the valid configs. ------------------------------------------------------------------------ Wed, 18 Feb 2004 15:14:02 +0000 : TDobes Adrian, thanks for all your work on the install system... I'll check it out once I get home this evening. Just FYI, here's a link to the XTemplate bug [1] you mentioned. (It's a simple two-line patch.) [1] http://drupal.org/node/view/5858 ------------------------------------------------------------------------ Sun, 20 Jun 2004 20:29:41 +0000 : adrian taking out of patch queue. Still on my todo list, but I have to get some other things done first. ------------------------------------------------------------------------ Tue, 27 Jul 2004 15:25:33 +0000 : JonBob The install system should (will?) handle version numbers. Some related issues to examine: None of these are really duplicates of one another, so while I'd like to close them I can't. Consider this a reminder to do so if and when the install system addresses the problems. New 'version' system field and Drupal version [2] Module dependencies [3] Show drupal version to admins [4] Meta tag with drupal version [5] Version number [6] [2] http://drupal.org/node/view/5811 [3] http://drupal.org/node/view/8402 [4] http://drupal.org/node/view/2986 [5] http://drupal.org/node/view/2828 [6] http://drupal.org/node/view/8762 ------------------------------------------------------------------------ Sun, 13 Mar 2005 16:03:52 +0000 : publian It made it based on install_phase2. It makes it with drupal CVS as of 2005.03.14. The improvement point is as follows. 1) The installation query command execution read database/database.mysql or database/database.pgsql. 2) Two head bytes of $_SERVER 'HTTP_ACCEPT_LANGUAGE' were seen, and the installation language was distinguished automatically. This sees the install.lang file in the languege folder. (funcution lt() like funcution t()) Making) 3)　In the installation process, the mother tongue can have been selected. (The import is done from the file in the translations folder. ) 4) Additionally, a detailed place was corrected. The bug moves though thinks many still. -- Drupal Japan ------------------------------------------------------------------------ Sun, 13 Mar 2005 16:10:10 +0000 : publian Attachment: http://drupal.org/files/issues/install_phase3.tar.gz (134.72 KB) It is as for appending. ------------------------------------------------------------------------ Sat, 26 Mar 2005 08:11:40 +0000 : judah I was just about to start creating an install system for modules when someone mentioned you were already working on one. Here is my design specs, http://drupal.org/node/19427 I could not contact you via any other means so please advise what the current status is on this. Thanks ------------------------------------------------------------------------ Wed, 30 Mar 2005 23:13:04 +0000 : adrian Attachment: http://drupal.org/files/issues/install_api_phase_1.tar.bz2 (21.49 KB) Attached is the first iteration of my new install system. To install : Extract tarball into a clean checkout, and apply the install_api_phase_1.patch file. This patch implements the following : * Core install api. /(includes/install.inc)/ * Modifications to drupal_load that disables a module that has an out of data schema. /(includes/bootstrap.inc)/ * Does not allow modules to be enabled unless they have been installed, or updated and the allow for them to be installed and updated directly from admin/modules. /(modules/system.module)/ This patch does NOT : Install or update Drupal core, however it is possible to do so with the api (and I have done so before), significant changes to Drupal need to happen before it is practical to handle core with it. Description : This is the first phase of a four or five phase project, so it's not meant to solve the whole problem. I am writing a post for the Drupal forums at present detailing the progress with the install system, and directions I want to take it. To enable a module to be installable, you add an implementation of hook_info() to it , i.e. : <?php function buddylist_info($key) { $info['schema'] = 1; return $info[$key]; } ?> This tells the system that a schema version of 1 is required to operate this module. You then create a file called modulename.install (preferably in the same directory in the module, although it doesn't really matter. You then need to specify which schema version it implements by : <?php function buddylist_schema($key) { $info['version'] = 1; return $info[$key]; } ?> Although, in the current implementation this function is optional when you only have a single schema version (the default is 1). Then you implement your hook_install(). <?php function buddylist_install() { $query = " CREATE TABLE {buddylist} ( uid int(10) UNSIGNED NOT NULL, buddy int(10) UNSIGNED NOT NULL, timestamp int(11) NOT NULL, PRIMARY KEY (uid, buddy) )"; db_query($query); db_query("ALTER TABLE {buddylist} ADD received tinyint(1) NOT NULL;"); } ?> This function would be called for any database type that has not specified it's own function. To add Postgres support, the function would be called buddylist_install_pgsql();. If the schema of your module ever changes, to allow for it to be updated, you proceed as follows : * increment the 'schema' value in your hook_info() function. * increment the 'version' value in your hook_schema function, within your modulename.install file. * modify your schema as required, by changing it in the hook_install() function. * provide an update script for users of the previous version. The following is an example of an update script. <?php function buddylist_update_1() { db_query("ALTER TABLE .... ..... "); } ?> These updates can also be database specific (ie: buddylist_update_1_pgsql() etc). When a module needs to be updated, it will execute each of the functions in order (exactly like one would in updates.inc currently.) I have included copies of the Trackback and Buddylist modules for testing. ------------------------------------------------------------------------ Thu, 31 Mar 2005 01:26:39 +0000 : FactoryJoe(a)civicspacelabs.org No idea if this is of any use, but I thought it would be cool if there were feeds for each module: http://www.speirs.org/appcasting/ Drumm calls it RSS for RSS' sake. Perhaps, but it's worth considering. ------------------------------------------------------------------------ Thu, 31 Mar 2005 10:09:12 +0000 : adrian Yeah. I've been planning that from the start (before it had a fancy name), I'm currently planning to have it happen around phase four or five. ------------------------------------------------------------------------ Mon, 09 May 2005 23:13:11 +0000 : adrian Here is that overview of the install system i promised weeks ago : http://drupal.org/node/22472 This is the first phase. ------------------------------------------------------------------------ Thu, 21 Jul 2005 20:15:39 +0000 : adrian Attachment: http://drupal.org/files/issues/install_api_phase_1.tar_0.bz2 (19.5 KB) Updated this patch to work with HEAD. as before, there are copies of the buddylist and trackback modules, just to illustrate the usage of the patch. 1 ) Extract into a HEAD install 2 ) patch with install_api_phase_1.patch 3 ) 'delete from cache' in your database (the menu cache is much maligned by myself) 4 ) Go to admin/modules and see the install links in place of enable. ------------------------------------------------------------------------ Sun, 24 Jul 2005 03:27:33 +0000 : stefan nagtegaal adrian, could you please post a patch instead of a packaged patch? I know it will be quite big, but makes code reviewing a little easier...

1 0

[drupal-devel] [bug] "Only variables can be passed by reference" to node_invoke()
by danielc 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/26235 Project: Drupal Version: 4.6.2 Component: node system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Attachment: http://drupal.org/files/issues/node_invoke.diff (858 bytes) A client of mine just upgraded to the latest snapshot of PHP 5.0.5-dev and started getting errors when node_invoke() is called: Fatal error: Only variables can be passed by reference in c:\drupal\modules\node.module on line 702. This patch fixes the problem by assigning the value to a variable before passing it to node_invoke(). Thanks. danielc

4 5

[drupal-devel] [feature] add inline functionaliy to uploads
by TDobes 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/26288 Post a follow up: http://drupal.org/project/comments/add/26288 Project: Drupal Version: cvs Component: upload.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: TDobes Status: patch Please don't combine unrelated changes together in the same patch. Moving stuff in/out of the _nodeapi hook has absolutely nothing to do with the patch and makes it much harder to read through the patch and see what it's actually doing. I'd appreciate it if you could separate the changes made here which are really relevant and move the other changes into another issue. Also: You change form_group_collapsible(t('File attachments') to form_group_collapsible(t('File Attachments'). A quick glance at some other core code seems to indicate that we've standardized on capitalizing only the first word in multi-word group titles. As for the functionality itself, I don't think this belongs in upload.module. It would be useful to have the functionality in core, but as a separate module which can be switched on and off. (upload_inline.module or something like that) If a site were set up using an inlining system from contrib and the functionality you're proposing could not be switched off, it would be extremely confusing to users that there are two different ways of inlining images. A minor comment: I'm not so sure whether the results of this patch, when inlining non-image attachments, will be the one users expect. A non-web-savvy person may expect his/her Word document (for instance) to appear inline with the node when they click "inline" -- just like their images do. I'd suggest that we limit inlining to images only. I'm not as adamant about this as the other issues, so I could be convinced otherwise if others disagree. TDobes Previous comments: ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:03:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline.patch (19.05 KB) One of the most often asked features is proper inlnie handling of files. Look at the amount of solutions, the popularity of image_assist, and the amount of peolpe dowloading image.module! That alone should be enough proof that Drupal lacks proper inline image support. This patch adds that to core. In fact, it does little more then appending a link of img tag to the body or the teaser. Off course that is configurable per file. Next to the [] list checkbox, this patch adds an [] inline checkbox. Simplicity is the foundation of this patch. I want no stles for inline editing, no fancy html wrappers, no tokens, just $node->body or teaser appended with a small html string. Another small themable funtion is introduced, (hey, you cannot expect me to develop something without adding more power for themers, now, can you? ;) ), that allows people to theme the string that is appended to the body or the teaser. Oh, and also note hat the biggest part of this patch is some cleaning I had to do in order to be able to develop properly. I dont like Ifs inside cases in foreaches inside swiches. in other words: nodeapi now calls functions instead of executing code directly. ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:25 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot.png (26.68 KB) here is how the form now looks ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:58 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot3.png (30.53 KB) and this is an example of inlined images and a .doc file. ------------------------------------------------------------------------ Sun, 03 Jul 2005 20:44:00 +0000 : sepeck changing to patch per request from berkes ------------------------------------------------------------------------ Tue, 05 Jul 2005 07:46:13 +0000 : Kobus This gets a +1 from me in principle, however, the [inline:xx] tag with inline.module gives you greater freedom as to where the inline image must be displayed. If you can add this functionality (I haven't checked the code, I don't know if it is in there) it would be a great addition for Core. This same strategy can be used for inline blocks, I am sure. Regards, Kobus ------------------------------------------------------------------------ Tue, 05 Jul 2005 08:57:50 +0000 : Bèr Kessels there are a couple of reasons why i did not include the [inline] tags. * I aimed for extreme simplicity: a checkbox shows an image inline: its up to the theme where it appears (if one does not like it before/above the body and teaser.). Simplicity was the main goal. * We don't have any tokens in core. And we should not have them. * Tokens are a very bad substitute for a good interface. They give less power then plain HTLM. Are much worst documented then HTML, but in the mean time, they are still as hard to learn as HTML. (Yes, I know people _think_ they are easier, but there _is_ not difference between [ ] and , only that its a different ascii char. So, no. I don't allow any placement of the image. I leave that that for dedicated modules, or the themer to decide. ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:34:06 +0000 : Kobus So you will provide an API to do this? For example, with perhaps minor modifications, the inline.module will be able to display these files? In that case I am happy. If not, then I can't give my support to this patch (as if that matters...). A themer can't do this task as inline images (and blocks for that matter) is too dynamic for theming; it can be placed anywhere in a node where the user pleases. This means for me that there should be a module for this, such as inline module that allows you to define [inline:xx] tags. If your module emits an array of uploaded files (such as upload.module), inline.module can be, with minor changes, adapted to show these files inline. To show you what I mean with the content is too dynamic for a themer to perform this task, look at this screenshot related to inline blocks (inline images can follow the same pattern): http://drupal.org/files/issues/regions---possibility-3.png ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:26:15 +0000 : Bèr Kessels Kobus, We are dealing with different issues here: You want a method to place images, files or so anywhere in the post. That is fine, but certainly NOT addressed in the patch! I made patch that *only* adds marked files to the body. its really nothing more then <?php $node->body = $filestring . $node->body ?> No APIS, no, dynamic tokens, no filters, nothing. However, what I meant with themers, is that there now is a theme_upload_inline available, so you can theme the abovementioned $filestring. On top of that $node->files[FILEID]->inline is TRUE if a file is flagged for inline. So in node.tpl.php, or wherever you want to theme a node, you can print nice images inline, when that flag is set. And about the comment that a themer cant do this: Simply not true. On most sites images are always placed in the same places. REally, even the sites see which use img_assist or inline, use them to place the images on the exact same places in every node. People /think/ they want the power to place images anywhere, but they hardly ever use that power. Just look at all the big news/publishing sites out there (BBC, CNN, BoigBoing, r even freshmeat) images are all placed acc. to the theme. They are not placed in random places by authors. So if you are one of the few that still want that power, there aer mots of power tools like inline module or img_assist. We should offer a good default, one that is simple. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:41:34 +0000 : Gerhard Killesreiter I fully agree that tags are evil. Kobus: You can always look for tags in $node->body in your theme's node function. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:50:52 +0000 : stefan nagtegaal Ber, the theme-function in your code looks like: <?php +/** + * Theme function for rendering of inline images + * @param $file a file object. + * @param $image a Boolean, indicating whether an img tag (TRUE) or an anchor tag (FALSE) should be used. + * @ingroup themable + */ +function theme_upload_inline($file, $image) { + if ($image) { + return '<img src="'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'" alt="'. check_plain($file->filename) .'" class="upload inline">'; + } + else { + return ''. check_plain($file->filename) .' [1]'; + } + +} ?> After looking at your code it's not clear to me when $image is TRUE or FALSE, can you elaborate on me please? [1] http://drupal.org/'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'\" class=\"upload inline ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:06:39 +0000 : Bèr Kessels The function calling the theme function should decide whether its an image. IMO that is far too hardcore code for a themer ;) <?php $image = ereg('^(image/)', $file->filemime); ?> inside _upload_inline() does the trick. I did find one issue, though, with svgs, which are image/svg so maybe we should limit this to really only inline jpg, png, and gif, by extension? But I am no fan of determining files by extension, and IMO getimgsize is too heavy; ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:13:52 +0000 : stefan nagtegaal Can't you make use of PHP's <?php image_type_to_mime_type(); ?> or <?php image_type_to_extension(); ?> ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:45:43 +0000 : Kobus Well, if not in the patch, I need inline functionality one way or another. inline.module works perfectly with the current upload.module to fulfill my needs, and if there is a way where someone can extend your proposed upload.module, that would get my +1, otherwise I will just remain neutral about this issue. inline.module makes use of $node->files and displays that image. If your patch still uses $node->files, then this is a non-issue. In other words, if I can, with inline.module, or with minor modifications to inline.module still show files inline, I am +1 for this. As for the themability question... I still disagree. You say "Simply not true. On most sites images are always placed in the same places." That is ONLY true because they have NO alternatives. Means the content is in the same places, because they have no other places to put them. I have made tens of static sites where the content does not resemble a fixed pattern or structure. For me, free-flow layout is my expression of my creativity. This is why I still even BOTHER with static sites; when Drupal don't do what I want it to do. If Drupal could do inline display of content properly, I'd never even build another static site. It is a great mistake people make (including myself), and that is they design the site before ANY content is available, and this happens a lot in static sites. But in dynamic sites, you have far less control over this, unless you have a VERY clean structure with limited information that can be added, and only a few people posting content. If you can have your content before you start the design, you will have a better fit. I can't see how you can anticipate every possible posting posted on your site if you have a diversity of users. Especially not if you're using a site such as an designer's showcase site where your creativity is shown by your web sites. Possible, but not easy. If I claim that I have "unique, fresh designs" I can certainly NOT give them a "box-like" site with "left and right side bars only". That's why I need inline content, this includes images AND boxes. Gerhard: Your concern about tags is answered as well above, if I am not mistaken. The patch need not provide the tags, but should provide for someone to develop a module that provide the filters or tags. To summarize: I don't need your patch to do the inline images. I just need your patch to be able to allow someone else to develop a module that can display inline files. Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 09:56:38 +0000 : Bèr Kessels okay, so for all clarity, let me sumarise: * this patch introduces a chackbox "inline". If checked, the file will show up inline. IT will be appended to the teaser and the body. * this patch does *not* allow one to place images of files in a userdefined place in the body. * this patch does *not* do any resizing nor any thumbnailing. * This patch is meant to be simple, clear and transparant. No tokens, no javascript, no nothing. ------------------------------------------------------------------------ Mon, 18 Jul 2005 11:21:54 +0000 : Kobus Then I can't see how this patch could replace the existing upload.module, which allows you to use inline.module to place images inline. I therefore withdraw my +1 and go -1 on this (not that it matters, I believe). I think you didn't properly read my previous message. I said I don't need your patch to do all this, but I can't live without the functionality currently provided by the upload.module and inline.module combination. I agree that your patch don't need to have that functionality, but if your patch takes away this functionality, in other words, I can't (by hook or by crook) manage what I need to do, my vote is -1. Regards, Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:58:34 +0000 : Bèr Kessels Kobus, And all the others looking fofr advanced inline systems: please do not -1 this. It will hep inline module a lot too. allthough not yet in this patch, but can you imagine a perission system for inline module, that comes for free? Or a core system, that makes inline module ten times smaller? it is this path! so, please, if it is not /exactly/ what you are looking for, at least look at the advantages for Joe Average, and even for the possibilties for your favorite inline-module. even imag_assist will gain an anomous usability impcact when usiong this module, for it can then finally use the upload module in full scale. Ber ------------------------------------------------------------------------ Sat, 23 Jul 2005 18:59:10 +0000 : Bèr Kessels Sohodjo jim: " I hope it matters. A big -1 on enforcing over-simplification at the expense of important and existing functionality. If automatic, uncontrollable placement of images becomes the standard, it will mean fewer not more image-rich Drupal sites as site owners/developers get complaints about "Why can't I control my images!" I _strongly_ encourage Ber to provide a "have it both ways" solution. Why not have an admin configuration setting for "allow inline tags" with default off. Change it to on and you get an additional upload checkbox for 'inline at tag' to accommodate the current functionality of the inline module while simultaneously allowing for default placement. " NOOO. people; please; look at the PATCH. Again: and hopefully last time: Simplicity. This patch does NOT replace ANYTHING inline module or img_assist wants to do. This patch hands better data to such modules. It hands a variable over to these modules, $node->file[FID]->inline, which tells these sorts of modules if people wnat that file to appear inline. AND it CAN (by default will) render a file in the most simple way inline. So really, if you want to -1 this patch, fine. But do not -1 it, because it does too little IYO. It still allows MUCH more than what you can do no, without that patch! And any solution, for core, that allows advanced handling of inline images will either require an enourmous amount of work, or it will simply no get in. So, unless you come up with a good core-worthy patch, this is still a big leap forward from what we have now. ------------------------------------------------------------------------ Sat, 23 Jul 2005 19:01:51 +0000 : Bèr Kessels :$ this is an attempt to fix the borken HML in the previous follow up.

1 0

[drupal-devel] [task] Drupal Install System
by stefan nagtegaal 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/5496 Post a follow up: http://drupal.org/project/comments/add/5496 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: stefan nagtegaal Status: patch adrian, could you please post a patch instead of a packaged patch? I know it will be quite big, but makes code reviewing a little easier... stefan nagtegaal Previous comments: ------------------------------------------------------------------------ Thu, 29 Jan 2004 09:10:25 +0000 : adrian I am in the process of developing a new Install API for the drupal core, which will allow a completely web based install / set up process, as well as allow contributed modules to integrate more directly into this system. A more detailed description of the system is available in this thread. This task has been created to place each of the successive patches in the patch queue. ------------------------------------------------------------------------ Thu, 29 Jan 2004 09:20:48 +0000 : adrian Attachment: http://drupal.org/files/issues/install_api_first_level.patch (6.42 KB) Kjartan correctly identified one of the problems in creating a unified install system. There's a lot of code that gets run by simply including the core files (bootstrap.inc, database.inc, session.inc and common.inc). A lot of this code relies upon the database connection going off without a hitch, like for instance the current system variables, themes and session code. To work around this i created a new drupal_init() function, which needs to be called when you want the system to initialize. drupal_init has a 'db_init' argument, which allows you to bypass the loading of all the database related code with a simple flag. install.php needs to run drupal core, while ignoring any database connections .. until atleast the point where the configuration settings for the database are entered, and confirmed to work. There is a new function created called 'database_connected()' , which returns a boolean true only if the database both connected and the table was selected successfully. This patch does not have a suitable error message for index.php upon not being able to make a database connection ,but that message should very likely be discussed and finalized. In the next level of the patch I will introduce the major changes, or rather additions. I haven't modified any existing files beyond the ones in this patch (at this time). ------------------------------------------------------------------------ Thu, 29 Jan 2004 12:24:15 +0000 : Kjartan This patch has some serious flaws though. <?php include_once "includes/bootstrap.inc"; -drupal_page_header(); include_once "includes/common.inc"; ?> By removing the drupal_page_header() you break the whole point of bootstrap as the common.inc stuff is included when its not necessary. It needs some more thought. Maybe you should take the time to make a workflow of the current Drupal init process before modifying it. Also the naming of constants, I would prefer calling them DATABASE_ATTEMPT as it makes it easier to tell them appart. ------------------------------------------------------------------------ Mon, 09 Feb 2004 20:18:35 +0000 : adrian I have reworked the patch into a very minimal set of requirements. To prevent the .inc files from running any code when you don't want them to , you 'define' a constant called 'DRUPAL_NO_INIT' before including bootstrap.inc. This relatively small patch is required for the install stuff to work. ------------------------------------------------------------------------ Mon, 09 Feb 2004 20:22:35 +0000 : adrian Attachment: http://drupal.org/files/issues/drupal_no_init_flag.patch (3.88 KB) i'll even attach it this time. ------------------------------------------------------------------------ Mon, 09 Feb 2004 20:48:06 +0000 : adrian Attachment: http://drupal.org/files/issues/database_init_return.patch (1.96 KB) The following patch is a modification to the includes/database*.inc set of files, to make db_connect return a boolean value depending on wether the connection was successfully made. I have changed database.inc to die() upon connection error with the message "Database Connection Unsuccessful". Cleaning up that message and placing a help page might be a good idea from an user experience point of view. This patch is required for the install system, in that it needs to test wether it has made a successfull database connection before it allows you to actually install the schema. ------------------------------------------------------------------------ Tue, 10 Feb 2004 01:15:14 +0000 : adrian Attachment: http://drupal.org/files/issues/install_system_alpha.tar.bz2 (11.59 KB) This is an alpha version of the new install API code. It is completely capable of installing the drupal core system without requiring any interaction with the database side. There are currently 5 configuration screens , but the API is sound for us to add / remove / change these screens as we need. In it's current state, it isn't capable of updating the base system, however the backend stubs exist, and have been tested. In the push to get the install process running smoothly i simply disabled the update interface. The previous 2 patches on this node need to be applied, but have been combined into install_system_alpha.patch which is included in this distribution. The rest of the files are new , and should not interfere with the drupal core at all. They are includes/install.inc ... the file that hosts the install api. install.php ... the front end script that initializes the install api (a total of 5 lines) install/system.install ... the install module for the core. It contains the bulk of code from update.php, and all the configuration information needed to successfully install the core. In the future , the install api will be able to easily install any contrib module through the modulename.install file that will hopefully become well supported. Note: I need to update the postgres compatibility in this .install file, and as such only mysql is fully tested now. I have posted some screenshots at my site ------------------------------------------------------------------------ Tue, 10 Feb 2004 18:22:02 +0000 : adrian Unconed just pointed out there is a conflict with windows installations in that there can not be an 'INSTALL' file and an 'install' directory (which contains the system.install currently) He suggested that we rename the README and INSTALL files to README.txt and INSTALL.txt. I personally move that we store the .install files within the modules directory , as in the future installing a contributed module should be as simple as dropping the module directory (containing .install , .module and whichever external files) into modules/ , and then installing the module within drupal. ------------------------------------------------------------------------ Thu, 12 Feb 2004 05:10:16 +0000 : moshe weitzman I played around with the patch, and successfully installed a new Drupal instance on the fitst try. Nice work, Adrian! I reviewed the code too, and found it quite Drupalish and satsfactory. Here are some notes from my install: - On the configuration file page, I selected from the radio button options a file which was not conf.php and thus did not exist. I strugged with the 'file is not writeable' error for a while until I realized that you expected me to create the file and then the installer would edit it ... in general, this page is a pretty complex introduction into drupal. I suggest simply assuming 'conf.php' here. I haven't thought about this much though. - Similar to above, I figured Drupal would create a database for me. Not so, I had to create it and then Drupal takes over. Some simple help text adddresses this point. - Use form_password() or similar when requesting a database password - The default $base_url was missing a slall for me. It said 'http://medrinstall' instead of 'http://me/drinstall' - After completing the DB install, there is no page telling you what to do next. A link to the home page is all thats needed IMO. -The site_name chosen during the install was not saved in the 'variable' table. - When you return to install.php some time later, you have no indication what a working site already exists. Not sure thats the right thing to do. Not a big deal though. P.S. Adrians suggestion to store the .install files in module specific subdirs under modules makes sense to me. Thus system.install would move to modules/system/system.install ------------------------------------------------------------------------ Fri, 13 Feb 2004 04:04:29 +0000 : skip I had to set up a pMachine blog yesterday for a client. I have to say... it was the easiest install process I've ever gone through (CMS-wise). Very user friendly. Lots of feedback to the user. If you haven't seen it before, you should check it out for ideas. ------------------------------------------------------------------------ Wed, 18 Feb 2004 05:26:10 +0000 : adrian Attachment: http://drupal.org/files/issues/install_phase2.tar.bz2 (12.96 KB) So I have spent far too much time over the last few weeks battling with this install system. My current results are in this here tarball. This time I am even less sure of it fully working in all cases, than last time. With this release I added extensive error checking to the install process, finished MOST of what is needed for the update process , but most importantly... it is a lot more secure than previously, and is specifically built to allow people to host their multiple drupal installs from just a single root. I have handled this by adding a global variable to the config file (allow_override_config) , which is checked by the install script before a new configuration file is made that would override the currently active one. There are three settings to this : 'no' , 'any' and 'auth'. I feel auth is generally the best option, as it requires anyone trying to override a working configuration file to enter the username and password for the site he is trying to override. Added checking also exists for the minimum requirements of running a drupal system (the tests probably need to be fleshed out), aswell as refusing to install a database dump into a db_url/db_prefix which seems to have a valid site installed. When a working configuration is detected on startup , the default action is to require the administrator user of the site to log in. This is for security reasons. The install script has lots of code that stops it from ever overwriting any config file that has already been created, but as I said .. it allows for the creation of a config file that will be parsed before the current valid install, but only with the express permission of that config. Config files have been moved to './conf/' , and the default config has been renamed to 'conf/default.php'. I have split install.inc into install.inc and install.module, as there was a lot of interface code specifically for the update/install sequence (and it is best available for reuse .. so i didnt wanna put it in install.php). This has an unrelated quirk for xtemplate .. I left it in the patch because for some reason I was unable to get a working default theme because xtemplate refused to populate the 'path' template variable. I also have an extensive 'gallery' of the new changes if you just want to see what it looks like. Directions for use : untar in a drupal cvs tree , and 'patch -p0 < install_alpha_2.patch' go to http://mysite/install.php ... previous configs in includes/ will be ignored for extra fun , create a hostname entry to sitea.siteb.sitec.sited.mysite , and watch the install script pick up the valid configs. ------------------------------------------------------------------------ Wed, 18 Feb 2004 15:14:02 +0000 : TDobes Adrian, thanks for all your work on the install system... I'll check it out once I get home this evening. Just FYI, here's a link to the XTemplate bug [1] you mentioned. (It's a simple two-line patch.) [1] http://drupal.org/node/view/5858 ------------------------------------------------------------------------ Sun, 20 Jun 2004 20:29:41 +0000 : adrian taking out of patch queue. Still on my todo list, but I have to get some other things done first. ------------------------------------------------------------------------ Tue, 27 Jul 2004 15:25:33 +0000 : JonBob The install system should (will?) handle version numbers. Some related issues to examine: None of these are really duplicates of one another, so while I'd like to close them I can't. Consider this a reminder to do so if and when the install system addresses the problems. New 'version' system field and Drupal version [2] Module dependencies [3] Show drupal version to admins [4] Meta tag with drupal version [5] Version number [6] [2] http://drupal.org/node/view/5811 [3] http://drupal.org/node/view/8402 [4] http://drupal.org/node/view/2986 [5] http://drupal.org/node/view/2828 [6] http://drupal.org/node/view/8762 ------------------------------------------------------------------------ Sun, 13 Mar 2005 16:03:52 +0000 : publian It made it based on install_phase2. It makes it with drupal CVS as of 2005.03.14. The improvement point is as follows. 1) The installation query command execution read database/database.mysql or database/database.pgsql. 2) Two head bytes of $_SERVER 'HTTP_ACCEPT_LANGUAGE' were seen, and the installation language was distinguished automatically. This sees the install.lang file in the languege folder. (funcution lt() like funcution t()) Making) 3)　In the installation process, the mother tongue can have been selected. (The import is done from the file in the translations folder. ) 4) Additionally, a detailed place was corrected. The bug moves though thinks many still. -- Drupal Japan ------------------------------------------------------------------------ Sun, 13 Mar 2005 16:10:10 +0000 : publian Attachment: http://drupal.org/files/issues/install_phase3.tar.gz (134.72 KB) It is as for appending. ------------------------------------------------------------------------ Sat, 26 Mar 2005 08:11:40 +0000 : judah I was just about to start creating an install system for modules when someone mentioned you were already working on one. Here is my design specs, http://drupal.org/node/19427 I could not contact you via any other means so please advise what the current status is on this. Thanks ------------------------------------------------------------------------ Wed, 30 Mar 2005 23:13:04 +0000 : adrian Attachment: http://drupal.org/files/issues/install_api_phase_1.tar.bz2 (21.49 KB) Attached is the first iteration of my new install system. To install : Extract tarball into a clean checkout, and apply the install_api_phase_1.patch file. This patch implements the following : * Core install api. /(includes/install.inc)/ * Modifications to drupal_load that disables a module that has an out of data schema. /(includes/bootstrap.inc)/ * Does not allow modules to be enabled unless they have been installed, or updated and the allow for them to be installed and updated directly from admin/modules. /(modules/system.module)/ This patch does NOT : Install or update Drupal core, however it is possible to do so with the api (and I have done so before), significant changes to Drupal need to happen before it is practical to handle core with it. Description : This is the first phase of a four or five phase project, so it's not meant to solve the whole problem. I am writing a post for the Drupal forums at present detailing the progress with the install system, and directions I want to take it. To enable a module to be installable, you add an implementation of hook_info() to it , i.e. : <?php function buddylist_info($key) { $info['schema'] = 1; return $info[$key]; } ?> This tells the system that a schema version of 1 is required to operate this module. You then create a file called modulename.install (preferably in the same directory in the module, although it doesn't really matter. You then need to specify which schema version it implements by : <?php function buddylist_schema($key) { $info['version'] = 1; return $info[$key]; } ?> Although, in the current implementation this function is optional when you only have a single schema version (the default is 1). Then you implement your hook_install(). <?php function buddylist_install() { $query = " CREATE TABLE {buddylist} ( uid int(10) UNSIGNED NOT NULL, buddy int(10) UNSIGNED NOT NULL, timestamp int(11) NOT NULL, PRIMARY KEY (uid, buddy) )"; db_query($query); db_query("ALTER TABLE {buddylist} ADD received tinyint(1) NOT NULL;"); } ?> This function would be called for any database type that has not specified it's own function. To add Postgres support, the function would be called buddylist_install_pgsql();. If the schema of your module ever changes, to allow for it to be updated, you proceed as follows : * increment the 'schema' value in your hook_info() function. * increment the 'version' value in your hook_schema function, within your modulename.install file. * modify your schema as required, by changing it in the hook_install() function. * provide an update script for users of the previous version. The following is an example of an update script. <?php function buddylist_update_1() { db_query("ALTER TABLE .... ..... "); } ?> These updates can also be database specific (ie: buddylist_update_1_pgsql() etc). When a module needs to be updated, it will execute each of the functions in order (exactly like one would in updates.inc currently.) I have included copies of the Trackback and Buddylist modules for testing. ------------------------------------------------------------------------ Thu, 31 Mar 2005 01:26:39 +0000 : FactoryJoe(a)civicspacelabs.org No idea if this is of any use, but I thought it would be cool if there were feeds for each module: http://www.speirs.org/appcasting/ Drumm calls it RSS for RSS' sake. Perhaps, but it's worth considering. ------------------------------------------------------------------------ Thu, 31 Mar 2005 10:09:12 +0000 : adrian Yeah. I've been planning that from the start (before it had a fancy name), I'm currently planning to have it happen around phase four or five. ------------------------------------------------------------------------ Mon, 09 May 2005 23:13:11 +0000 : adrian Here is that overview of the install system i promised weeks ago : http://drupal.org/node/22472 This is the first phase. ------------------------------------------------------------------------ Thu, 21 Jul 2005 20:15:39 +0000 : adrian Attachment: http://drupal.org/files/issues/install_api_phase_1.tar_0.bz2 (19.5 KB) Updated this patch to work with HEAD. as before, there are copies of the buddylist and trackback modules, just to illustrate the usage of the patch. 1 ) Extract into a HEAD install 2 ) patch with install_api_phase_1.patch 3 ) 'delete from cache' in your database (the menu cache is much maligned by myself) 4 ) Go to admin/modules and see the install links in place of enable.

1 0

[drupal-devel] [bug] Title not showing up correctly if there is no slogan
by c1pher 24 Jul '05

24 Jul '05

Issue status update for http://drupal.org/node/27346 Post a follow up: http://drupal.org/project/comments/add/27346 Project: Drupal Version: 4.6.2 Component: theme system Category: bug reports Priority: normal Assigned to: c1pher Reported by: c1pher Updated by: c1pher Status: patch Attachment: http://drupal.org/files/issues/titlepatch (484 bytes) If you have a site without a slogan it will show up as Oopsyouredead.com | - Browser Name. I already fixed the issue and am attaching a patch for it. The patch needs to be applied to the drupal/themes/engines/xtemplate/xtemplate.engine file. It just adds another turnary condition that if there isn't a slogan, it just does the site name. I'm a programmer, but I've never learned PHP;however, the fix worked. c1pher

1 0

[drupal-devel] [feature] add inline functionaliy to uploads
by Bèr Kessels 23 Jul '05

23 Jul '05

Issue status update for http://drupal.org/node/26288 Post a follow up: http://drupal.org/project/comments/add/26288 Project: Drupal Version: cvs Component: upload.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Sohodjo jim: " I hope it matters. A big -1 on enforcing over-simplification at the expense of important and existing functionality. If automatic, uncontrollable placement of images becomes the standard, it will mean fewer not more image-rich Drupal sites as site owners/developers get complaints about "Why can't I control my images!" I _strongly_ encourage Ber to provide a "have it both ways" solution. Why not have an admin configuration setting for "allow inline tags" with default off. Change it to on and you get an additional upload checkbox for 'inline at tag' to accommodate the current functionality of the inline module while simultaneously allowing for default placement. " NOOO. people; please; look at the PATCH. Again: and hopefully last time: Simplicity. This patch does NOT replace ANYTHING inline module or img_assist wants to do. This patch hands better data to such modules. It hands a variable over to these modules, $node->file[FID]->inline, which tells these sorts of modules if people wnat that file to appear inline. AND it CAN (by default will) render a file in the most simple way inline. So really, if you want to -1 this patch, fine. But do not -1 it, because it does too little IYO. It still allows MUCH more than what you can do no, without that patch! And any solution, for core, that allows advanced handling of inline images will either require an enourmous amount of work, or it will simply no get in. So, unless you come up with a good core-worthy patch, this is still a big leap forward from what we have now. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:03:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline.patch (19.05 KB) One of the most often asked features is proper inlnie handling of files. Look at the amount of solutions, the popularity of image_assist, and the amount of peolpe dowloading image.module! That alone should be enough proof that Drupal lacks proper inline image support. This patch adds that to core. In fact, it does little more then appending a link of img tag to the body or the teaser. Off course that is configurable per file. Next to the [] list checkbox, this patch adds an [] inline checkbox. Simplicity is the foundation of this patch. I want no stles for inline editing, no fancy html wrappers, no tokens, just $node->body or teaser appended with a small html string. Another small themable funtion is introduced, (hey, you cannot expect me to develop something without adding more power for themers, now, can you? ;) ), that allows people to theme the string that is appended to the body or the teaser. Oh, and also note hat the biggest part of this patch is some cleaning I had to do in order to be able to develop properly. I dont like Ifs inside cases in foreaches inside swiches. in other words: nodeapi now calls functions instead of executing code directly. ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:25 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot.png (26.68 KB) here is how the form now looks ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:58 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot3.png (30.53 KB) and this is an example of inlined images and a .doc file. ------------------------------------------------------------------------ Sun, 03 Jul 2005 20:44:00 +0000 : sepeck changing to patch per request from berkes ------------------------------------------------------------------------ Tue, 05 Jul 2005 07:46:13 +0000 : Kobus This gets a +1 from me in principle, however, the [inline:xx] tag with inline.module gives you greater freedom as to where the inline image must be displayed. If you can add this functionality (I haven't checked the code, I don't know if it is in there) it would be a great addition for Core. This same strategy can be used for inline blocks, I am sure. Regards, Kobus ------------------------------------------------------------------------ Tue, 05 Jul 2005 08:57:50 +0000 : Bèr Kessels there are a couple of reasons why i did not include the [inline] tags. * I aimed for extreme simplicity: a checkbox shows an image inline: its up to the theme where it appears (if one does not like it before/above the body and teaser.). Simplicity was the main goal. * We don't have any tokens in core. And we should not have them. * Tokens are a very bad substitute for a good interface. They give less power then plain HTLM. Are much worst documented then HTML, but in the mean time, they are still as hard to learn as HTML. (Yes, I know people _think_ they are easier, but there _is_ not difference between [ ] and , only that its a different ascii char. So, no. I don't allow any placement of the image. I leave that that for dedicated modules, or the themer to decide. ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:34:06 +0000 : Kobus So you will provide an API to do this? For example, with perhaps minor modifications, the inline.module will be able to display these files? In that case I am happy. If not, then I can't give my support to this patch (as if that matters...). A themer can't do this task as inline images (and blocks for that matter) is too dynamic for theming; it can be placed anywhere in a node where the user pleases. This means for me that there should be a module for this, such as inline module that allows you to define [inline:xx] tags. If your module emits an array of uploaded files (such as upload.module), inline.module can be, with minor changes, adapted to show these files inline. To show you what I mean with the content is too dynamic for a themer to perform this task, look at this screenshot related to inline blocks (inline images can follow the same pattern): http://drupal.org/files/issues/regions---possibility-3.png ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:26:15 +0000 : Bèr Kessels Kobus, We are dealing with different issues here: You want a method to place images, files or so anywhere in the post. That is fine, but certainly NOT addressed in the patch! I made patch that *only* adds marked files to the body. its really nothing more then <?php $node->body = $filestring . $node->body ?> No APIS, no, dynamic tokens, no filters, nothing. However, what I meant with themers, is that there now is a theme_upload_inline available, so you can theme the abovementioned $filestring. On top of that $node->files[FILEID]->inline is TRUE if a file is flagged for inline. So in node.tpl.php, or wherever you want to theme a node, you can print nice images inline, when that flag is set. And about the comment that a themer cant do this: Simply not true. On most sites images are always placed in the same places. REally, even the sites see which use img_assist or inline, use them to place the images on the exact same places in every node. People /think/ they want the power to place images anywhere, but they hardly ever use that power. Just look at all the big news/publishing sites out there (BBC, CNN, BoigBoing, r even freshmeat) images are all placed acc. to the theme. They are not placed in random places by authors. So if you are one of the few that still want that power, there aer mots of power tools like inline module or img_assist. We should offer a good default, one that is simple. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:41:34 +0000 : Gerhard Killesreiter I fully agree that tags are evil. Kobus: You can always look for tags in $node->body in your theme's node function. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:50:52 +0000 : stefan nagtegaal Ber, the theme-function in your code looks like: <?php +/** + * Theme function for rendering of inline images + * @param $file a file object. + * @param $image a Boolean, indicating whether an img tag (TRUE) or an anchor tag (FALSE) should be used. + * @ingroup themable + */ +function theme_upload_inline($file, $image) { + if ($image) { + return '<img src="'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'" alt="'. check_plain($file->filename) .'" class="upload inline">'; + } + else { + return ''. check_plain($file->filename) .' [1]'; + } + +} ?> After looking at your code it's not clear to me when $image is TRUE or FALSE, can you elaborate on me please? [1] http://drupal.org/'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'\" class=\"upload inline ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:06:39 +0000 : Bèr Kessels The function calling the theme function should decide whether its an image. IMO that is far too hardcore code for a themer ;) <?php $image = ereg('^(image/)', $file->filemime); ?> inside _upload_inline() does the trick. I did find one issue, though, with svgs, which are image/svg so maybe we should limit this to really only inline jpg, png, and gif, by extension? But I am no fan of determining files by extension, and IMO getimgsize is too heavy; ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:13:52 +0000 : stefan nagtegaal Can't you make use of PHP's <?php image_type_to_mime_type(); ?> or <?php image_type_to_extension(); ?> ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:45:43 +0000 : Kobus Well, if not in the patch, I need inline functionality one way or another. inline.module works perfectly with the current upload.module to fulfill my needs, and if there is a way where someone can extend your proposed upload.module, that would get my +1, otherwise I will just remain neutral about this issue. inline.module makes use of $node->files and displays that image. If your patch still uses $node->files, then this is a non-issue. In other words, if I can, with inline.module, or with minor modifications to inline.module still show files inline, I am +1 for this. As for the themability question... I still disagree. You say "Simply not true. On most sites images are always placed in the same places." That is ONLY true because they have NO alternatives. Means the content is in the same places, because they have no other places to put them. I have made tens of static sites where the content does not resemble a fixed pattern or structure. For me, free-flow layout is my expression of my creativity. This is why I still even BOTHER with static sites; when Drupal don't do what I want it to do. If Drupal could do inline display of content properly, I'd never even build another static site. It is a great mistake people make (including myself), and that is they design the site before ANY content is available, and this happens a lot in static sites. But in dynamic sites, you have far less control over this, unless you have a VERY clean structure with limited information that can be added, and only a few people posting content. If you can have your content before you start the design, you will have a better fit. I can't see how you can anticipate every possible posting posted on your site if you have a diversity of users. Especially not if you're using a site such as an designer's showcase site where your creativity is shown by your web sites. Possible, but not easy. If I claim that I have "unique, fresh designs" I can certainly NOT give them a "box-like" site with "left and right side bars only". That's why I need inline content, this includes images AND boxes. Gerhard: Your concern about tags is answered as well above, if I am not mistaken. The patch need not provide the tags, but should provide for someone to develop a module that provide the filters or tags. To summarize: I don't need your patch to do the inline images. I just need your patch to be able to allow someone else to develop a module that can display inline files. Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 09:56:38 +0000 : Bèr Kessels okay, so for all clarity, let me sumarise: * this patch introduces a chackbox "inline". If checked, the file will show up inline. IT will be appended to the teaser and the body. * this patch does *not* allow one to place images of files in a userdefined place in the body. * this patch does *not* do any resizing nor any thumbnailing. * This patch is meant to be simple, clear and transparant. No tokens, no javascript, no nothing. ------------------------------------------------------------------------ Mon, 18 Jul 2005 11:21:54 +0000 : Kobus Then I can't see how this patch could replace the existing upload.module, which allows you to use inline.module to place images inline. I therefore withdraw my +1 and go -1 on this (not that it matters, I believe). I think you didn't properly read my previous message. I said I don't need your patch to do all this, but I can't live without the functionality currently provided by the upload.module and inline.module combination. I agree that your patch don't need to have that functionality, but if your patch takes away this functionality, in other words, I can't (by hook or by crook) manage what I need to do, my vote is -1. Regards, Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:58:34 +0000 : Bèr Kessels Kobus, And all the others looking fofr advanced inline systems: please do not -1 this. It will hep inline module a lot too. allthough not yet in this patch, but can you imagine a perission system for inline module, that comes for free? Or a core system, that makes inline module ten times smaller? it is this path! so, please, if it is not /exactly/ what you are looking for, at least look at the advantages for Joe Average, and even for the possibilties for your favorite inline-module. even imag_assist will gain an anomous usability impcact when usiong this module, for it can then finally use the upload module in full scale. Ber

2 1

[drupal-devel] [bug] Category selection does not work with Movable Type blogapi
by mrmachine 23 Jul '05

23 Jul '05

Issue status update for http://drupal.org/node/24030 Post a follow up: http://drupal.org/project/comments/add/24030 Project: Drupal Version: 4.6.2 Component: blogapi.module Category: bug reports Priority: normal Assigned to: walkah Reported by: mrmachine Updated by: mrmachine Status: patch "am i able to use the same patch to "not fix" 4.6.2? " no. no i can't. i'd really like to test any possible fixes. are there any? mrmachine Previous comments: ------------------------------------------------------------------------ Tue, 31 May 2005 22:38:14 +0000 : mrmachine Using a blog client (linux - either Drivel or BlogTK) and the Moveable Type api, you can retrieve categories and select one for your post, but once the post is submitted, it fails to allocate the category - making the use of a blog tool pretty useless. ------------------------------------------------------------------------ Tue, 31 May 2005 22:45:51 +0000 : laura s I use ecto, set to MoveableType API,but so far I'm not able to repeat this problem. Could it be the client? I was also able to set Drupal's BlogAPI to the MetaWeblog setting and it seemed to work fine -- even with ecto set to MoveableType API. You might be able to try that as a workaround. ------------------------------------------------------------------------ Thu, 02 Jun 2005 12:04:12 +0000 : mrmachine I tried ecto on my son's Windows box, and yes - it does set categories correctly ... too bad there's no linux version but anyway, i tried changing Drupal's blogapi to Metaweblog, and kept Drivel and BlogTK set to Moveable Type API. It didn't work for Drivel, but it did for BlogTK ... thanx for the hint! ------------------------------------------------------------------------ Sun, 05 Jun 2005 14:36:44 +0000 : fflewddur I've been trouble-shooting this issue using w.bloggar on Windows and Drivel on Linux. w.bloggar is able to post using the Movable Type API, but the category selection only works if you click "Post", not "Post and Publish". Drivel, by default, publishes all posts, which is why the category never shows up when using Drivel with Drupal. To post entries with categories to an official Movable Type implementation, the client must first post the entry, then call mt.setPostCategories, and then call mt.publishPost. The mt.publishPost call is what seems to be confusing Drupal, as it doesn't appear to differentiate between a post that has been published with one which has. Movable Type does not publicly display posts which have not been published; it considers them as drafts which the author has not yet finished. Thus, Movable Type servers require the mt.publishPost call. I have Ethereal traces of several example posts to Drupal using both w.bloggar in "post" and "post and publish" mode, as well as Drivel. If you think they'd be useful in debugging, let me know and I'll forward them on to you. Cheers, Todd ------------------------------------------------------------------------ Thu, 09 Jun 2005 03:57:11 +0000 : mrmachine has anyone had a chance to look at this since Todd debugged it? ------------------------------------------------------------------------ Mon, 13 Jun 2005 20:56:58 +0000 : mrmachine can someone have a look at this? ------------------------------------------------------------------------ Tue, 14 Jun 2005 00:05:25 +0000 : walkah Attachment: http://drupal.org/files/issues/blogapi-publish-post.patch (634 bytes) having a look - it seems that mt.publishPost may well have been wiping the term info set by setCategory. As I only have ecto available to me currently, I can't test this patch... but if I understand the debugging work correctly - this should fix it. (the difference being ecto and MarsEdit - the two that I have access to currently - don't call publishPost). please confirm this fixes things... thanks. (I'll test more when I'm home again at the end of the week). ------------------------------------------------------------------------ Tue, 14 Jun 2005 23:06:29 +0000 : mrmachine beauty! this has fixed it for me! thanx shayne ------------------------------------------------------------------------ Wed, 15 Jun 2005 04:29:48 +0000 : baudolino This is not fixed until a decision about whether to commit this patch is made. Reverting this to patch status. ------------------------------------------------------------------------ Sun, 19 Jun 2005 20:25:55 +0000 : Dries Actually, this is an annoying property of node_save() ... I guess you can't use node_invoke_nodeapi($node, 'insert') or node_invoke_nodeapi($node, 'update')? ------------------------------------------------------------------------ Thu, 23 Jun 2005 17:53:32 +0000 : walkah i'm not sure that'd make a difference, would it? isn't the issue that $node->taxonomy is unset? ------------------------------------------------------------------------ Wed, 20 Jul 2005 11:56:50 +0000 : mrmachine i upgraded to 4.6.2 (a tad late though - i'd been hacked), and am now back to the original problem (i.e. - using Drivel or BloGTK, i am unable to set the category - i can choose one, but it doesn't stick) ... i'm guessing it's because this is "not fixed" and so wasn't committed with the 4.6.2 release. am i able to use the same patch to "not fix" 4.6.2? in doing so, i won't mess up any 4.6.2 security patches, will i? shayne

1 0

[drupal-devel] [feature] add inline functionaliy to uploads
by Bèr Kessels 23 Jul '05

23 Jul '05

Issue status update for http://drupal.org/node/26288 Post a follow up: http://drupal.org/project/comments/add/26288 Project: Drupal Version: cvs Component: upload.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch :$ this is an attempt to fix the borken HML in the previous follow up. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:03:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/upload_inline.patch (19.05 KB) One of the most often asked features is proper inlnie handling of files. Look at the amount of solutions, the popularity of image_assist, and the amount of peolpe dowloading image.module! That alone should be enough proof that Drupal lacks proper inline image support. This patch adds that to core. In fact, it does little more then appending a link of img tag to the body or the teaser. Off course that is configurable per file. Next to the [] list checkbox, this patch adds an [] inline checkbox. Simplicity is the foundation of this patch. I want no stles for inline editing, no fancy html wrappers, no tokens, just $node->body or teaser appended with a small html string. Another small themable funtion is introduced, (hey, you cannot expect me to develop something without adding more power for themers, now, can you? ;) ), that allows people to theme the string that is appended to the body or the teaser. Oh, and also note hat the biggest part of this patch is some cleaning I had to do in order to be able to develop properly. I dont like Ifs inside cases in foreaches inside swiches. in other words: nodeapi now calls functions instead of executing code directly. ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:25 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot.png (26.68 KB) here is how the form now looks ------------------------------------------------------------------------ Sun, 03 Jul 2005 18:19:58 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/inline.patch.screenshot3.png (30.53 KB) and this is an example of inlined images and a .doc file. ------------------------------------------------------------------------ Sun, 03 Jul 2005 20:44:00 +0000 : sepeck changing to patch per request from berkes ------------------------------------------------------------------------ Tue, 05 Jul 2005 07:46:13 +0000 : Kobus This gets a +1 from me in principle, however, the [inline:xx] tag with inline.module gives you greater freedom as to where the inline image must be displayed. If you can add this functionality (I haven't checked the code, I don't know if it is in there) it would be a great addition for Core. This same strategy can be used for inline blocks, I am sure. Regards, Kobus ------------------------------------------------------------------------ Tue, 05 Jul 2005 08:57:50 +0000 : Bèr Kessels there are a couple of reasons why i did not include the [inline] tags. * I aimed for extreme simplicity: a checkbox shows an image inline: its up to the theme where it appears (if one does not like it before/above the body and teaser.). Simplicity was the main goal. * We don't have any tokens in core. And we should not have them. * Tokens are a very bad substitute for a good interface. They give less power then plain HTLM. Are much worst documented then HTML, but in the mean time, they are still as hard to learn as HTML. (Yes, I know people _think_ they are easier, but there _is_ not difference between [ ] and , only that its a different ascii char. So, no. I don't allow any placement of the image. I leave that that for dedicated modules, or the themer to decide. ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:34:06 +0000 : Kobus So you will provide an API to do this? For example, with perhaps minor modifications, the inline.module will be able to display these files? In that case I am happy. If not, then I can't give my support to this patch (as if that matters...). A themer can't do this task as inline images (and blocks for that matter) is too dynamic for theming; it can be placed anywhere in a node where the user pleases. This means for me that there should be a module for this, such as inline module that allows you to define [inline:xx] tags. If your module emits an array of uploaded files (such as upload.module), inline.module can be, with minor changes, adapted to show these files inline. To show you what I mean with the content is too dynamic for a themer to perform this task, look at this screenshot related to inline blocks (inline images can follow the same pattern): http://drupal.org/files/issues/regions---possibility-3.png ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:26:15 +0000 : Bèr Kessels Kobus, We are dealing with different issues here: You want a method to place images, files or so anywhere in the post. That is fine, but certainly NOT addressed in the patch! I made patch that *only* adds marked files to the body. its really nothing more then <?php $node->body = $filestring . $node->body ?> No APIS, no, dynamic tokens, no filters, nothing. However, what I meant with themers, is that there now is a theme_upload_inline available, so you can theme the abovementioned $filestring. On top of that $node->files[FILEID]->inline is TRUE if a file is flagged for inline. So in node.tpl.php, or wherever you want to theme a node, you can print nice images inline, when that flag is set. And about the comment that a themer cant do this: Simply not true. On most sites images are always placed in the same places. REally, even the sites see which use img_assist or inline, use them to place the images on the exact same places in every node. People /think/ they want the power to place images anywhere, but they hardly ever use that power. Just look at all the big news/publishing sites out there (BBC, CNN, BoigBoing, r even freshmeat) images are all placed acc. to the theme. They are not placed in random places by authors. So if you are one of the few that still want that power, there aer mots of power tools like inline module or img_assist. We should offer a good default, one that is simple. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:41:34 +0000 : Gerhard Killesreiter I fully agree that tags are evil. Kobus: You can always look for tags in $node->body in your theme's node function. ------------------------------------------------------------------------ Tue, 05 Jul 2005 11:50:52 +0000 : stefan nagtegaal Ber, the theme-function in your code looks like: <?php +/** + * Theme function for rendering of inline images + * @param $file a file object. + * @param $image a Boolean, indicating whether an img tag (TRUE) or an anchor tag (FALSE) should be used. + * @ingroup themable + */ +function theme_upload_inline($file, $image) { + if ($image) { + return '<img src="'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'" alt="'. check_plain($file->filename) .'" class="upload inline">'; + } + else { + return ''. check_plain($file->filename) .' [1]'; + } + +} ?> After looking at your code it's not clear to me when $image is TRUE or FALSE, can you elaborate on me please? [1] http://drupal.org/'. check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())))) .'\" class=\"upload inline ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:06:39 +0000 : Bèr Kessels The function calling the theme function should decide whether its an image. IMO that is far too hardcore code for a themer ;) <?php $image = ereg('^(image/)', $file->filemime); ?> inside _upload_inline() does the trick. I did find one issue, though, with svgs, which are image/svg so maybe we should limit this to really only inline jpg, png, and gif, by extension? But I am no fan of determining files by extension, and IMO getimgsize is too heavy; ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:13:52 +0000 : stefan nagtegaal Can't you make use of PHP's <?php image_type_to_mime_type(); ?> or <?php image_type_to_extension(); ?> ------------------------------------------------------------------------ Tue, 05 Jul 2005 12:45:43 +0000 : Kobus Well, if not in the patch, I need inline functionality one way or another. inline.module works perfectly with the current upload.module to fulfill my needs, and if there is a way where someone can extend your proposed upload.module, that would get my +1, otherwise I will just remain neutral about this issue. inline.module makes use of $node->files and displays that image. If your patch still uses $node->files, then this is a non-issue. In other words, if I can, with inline.module, or with minor modifications to inline.module still show files inline, I am +1 for this. As for the themability question... I still disagree. You say "Simply not true. On most sites images are always placed in the same places." That is ONLY true because they have NO alternatives. Means the content is in the same places, because they have no other places to put them. I have made tens of static sites where the content does not resemble a fixed pattern or structure. For me, free-flow layout is my expression of my creativity. This is why I still even BOTHER with static sites; when Drupal don't do what I want it to do. If Drupal could do inline display of content properly, I'd never even build another static site. It is a great mistake people make (including myself), and that is they design the site before ANY content is available, and this happens a lot in static sites. But in dynamic sites, you have far less control over this, unless you have a VERY clean structure with limited information that can be added, and only a few people posting content. If you can have your content before you start the design, you will have a better fit. I can't see how you can anticipate every possible posting posted on your site if you have a diversity of users. Especially not if you're using a site such as an designer's showcase site where your creativity is shown by your web sites. Possible, but not easy. If I claim that I have "unique, fresh designs" I can certainly NOT give them a "box-like" site with "left and right side bars only". That's why I need inline content, this includes images AND boxes. Gerhard: Your concern about tags is answered as well above, if I am not mistaken. The patch need not provide the tags, but should provide for someone to develop a module that provide the filters or tags. To summarize: I don't need your patch to do the inline images. I just need your patch to be able to allow someone else to develop a module that can display inline files. Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 09:56:38 +0000 : Bèr Kessels okay, so for all clarity, let me sumarise: * this patch introduces a chackbox "inline". If checked, the file will show up inline. IT will be appended to the teaser and the body. * this patch does *not* allow one to place images of files in a userdefined place in the body. * this patch does *not* do any resizing nor any thumbnailing. * This patch is meant to be simple, clear and transparant. No tokens, no javascript, no nothing. ------------------------------------------------------------------------ Mon, 18 Jul 2005 11:21:54 +0000 : Kobus Then I can't see how this patch could replace the existing upload.module, which allows you to use inline.module to place images inline. I therefore withdraw my +1 and go -1 on this (not that it matters, I believe). I think you didn't properly read my previous message. I said I don't need your patch to do all this, but I can't live without the functionality currently provided by the upload.module and inline.module combination. I agree that your patch don't need to have that functionality, but if your patch takes away this functionality, in other words, I can't (by hook or by crook) manage what I need to do, my vote is -1. Regards, Kobus ------------------------------------------------------------------------ Mon, 18 Jul 2005 19:58:34 +0000 : Bèr Kessels Kobus, And all the others looking fofr advanced inline systems: please do not -1 this. It will hep inline module a lot too. allthough not yet in this patch, but can you imagine a perission system for inline module, that comes for free? Or a core system, that makes inline module ten times smaller? it is this path! so, please, if it is not /exactly/ what you are looking for, at least look at the advantages for Joe Average, and even for the possibilties for your favorite inline-module. even imag_assist will gain an anomous usability impcact when usiong this module, for it can then finally use the upload module in full scale. Ber ------------------------------------------------------------------------ Sat, 23 Jul 2005 18:59:10 +0000 : Bèr Kessels Sohodjo jim: " I hope it matters. A big -1 on enforcing over-simplification at the expense of important and existing functionality. If automatic, uncontrollable placement of images becomes the standard, it will mean fewer not more image-rich Drupal sites as site owners/developers get complaints about "Why can't I control my images!" I _strongly_ encourage Ber to provide a "have it both ways" solution. Why not have an admin configuration setting for "allow inline tags" with default off. Change it to on and you get an additional upload checkbox for 'inline at tag' to accommodate the current functionality of the inline module while simultaneously allowing for default placement. " NOOO. people; please; look at the PATCH. Again: and hopefully last time: Simplicity. This patch does NOT replace ANYTHING inline module or img_assist wants to do. This patch hands better data to such modules. It hands a variable over to these modules, $node->file[FID]->inline, which tells these sorts of modules if people wnat that file to appear inline. AND it CAN (by default will) render a file in the most simple way inline. So really, if you want to -1 this patch, fine. But do not -1 it, because it does too little IYO. It still allows MUCH more than what you can do no, without that patch! And any solution, for core, that allows advanced handling of inline images will either require an enourmous amount of work, or it will simply no get in. So, unless you come up with a good core-worthy patch, this is still a big leap forward from what we have now.

1 0