- Development - lists.drupal.org

[drupal-devel] Re: [drupal.org] LaTeX content
by puregin 23 Apr '05

23 Apr '05

On 20 Apr 2005, at 8:47 PM, Matt Schwartz wrote: > Djun, > > My goal is to eventually have drupal books exportable in a variety of > formats, including LaTeX. I haven't had time to look into the LaTeX > exporting yet. Since I want to literally output a book from generic > drupal nodes I'm not sure how we'd handle mathematics. I don't want to > have to rely on a special input format (i.e. drupal filter). If I understand you, your intention to store source as HTML, and convert to your export formats on the fly. Is this correct? I don't know what kind of applications you actually have in mind. In my experience, though, if you want to produce a high quality printed book that works as a book, you need to start with markup that supports print intentions. This isn't a problem if you intend to take an existing Drupal book, export it, and edit it heavily in the exported format. Probably life will be easier for the editor with this task if certain conventions can be enforced on the source text, either explicitly by the book module or implicitly through the cooperation of your contributors. > So unfortunately I don't currently have any code that can help you. I'm interested in a slightly different problem, namely having nodes contain LaTeX (to start with, perhaps later also MathML and other sources.) There's a certain amount of interest in using DocBook XML as a native format for Drupal Documentation, so perhaps there will be some overlap with this project, if it gets off of the ground. The LaTeX input would then be transformed into various output formats including HTML, which would be put back into a Drupal 'proxy' node for the source. This gives a kind of 'WYSIWYG' arrangement. A bit kludgy, but hopefully good enough. > What are your thoughts on how it might work? How would you like > authors > to input their mathematical content into drupal? I think that there's a number of projects which attempt to convert HTML to LaTeX. I've not looked closely at these - search for html2tex and you'll be on your way. Unfortunately, this transformation is basically 'just guessing'. Still, it's probably a good way to start. 'Better than nothing!' . And certainly an interesting problem/process. I've been doing some work trying to go directly from HTML to PDF, and this might be a way to achieve more control, so I'm keen to look into it further. Regarding mathematical input, TeX/LaTeX is pretty standard among people with serious mathematics editing / publishing requirements.' MathML is intended for machine generation/transformation. It's way too painful to type much of this. However, there's some tools for MathML to TeX/LaTeX, so supporting some kind of import is probably a good idea. This would allow people to edit in a convenient GUI on their desktop, and upload to Drupal via MathML. > > - Matt > > puregin(a)puregin.org wrote: >> Salve Veridicus, >> >> How is your work on LaTeX content management coming along? What are >> your >> envisioned use cases? Do you have a prototype or demo page? >> I'm interested in community authorship of mathematics. I'd like to >> have >> TeX/LaTeX content with full versioning, merging and diffs, chapters >> and >> section structures handled via Drupal books. >> >> Looking forward to hearing from you... >> >> Djun >> -- Djun M. Kim, Director djun.kim(a)cielosystems.com Cielo Systems Inc. http://www.cielosystems.com Strategic Software Research Tel: (604) 739-3941 302 - 1298 10th Avenue West FAX: (604) 739-3943 Vancouver, BC, V6H 1J4 Mobile:(778) 895-1379

2 1

[drupal-devel] [task] Consistent return 'passive voice' in form_set_error() and drupal_set_message()
by stefan nagtegaal 23 Apr '05

23 Apr '05

Issue status update for http://drupal.org/node/15595 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: stefan nagtegaal Reported by: bertboerland(a)www.drop.org Updated by: stefan nagtegaal -Status: active +Status: patch Setting status to Patch. stefan nagtegaal Previous comments: ------------------------------------------------------------------------ January 14, 2005 - 15:59 : bertboerland(a)www.drop.org *My* drupal not *Yours*! I think that when one addresses the user or the administrator of a site, it is best to do this outside in instead of inside out. So when in the documentation the coder is referring to the site of the administrator, this site should be called "your site" (/inside out/) but "my site" (/outside in/). There are numours examples where the text in referring to "your"where "my"would be apopriate [1] There used to be some "your" in the userinterface for the enduser as well, but that has been solved in 4.5. Before that you had "my account", but "track your postings". This has now all beens replaced by "my"and "mine". If everybody agrees, lets also corect this for the administrator as well; my administrator, not yours ;-) [1] examples: admin/logs/referrers "...that point to your web site." admin/settings "General configuration options for your site" ------------------------------------------------------------------------ April 19, 2005 - 18:36 : stefan nagtegaal We should consistently use the 'passive voice', when returning messages using form_set_error() and drupal_set_message(). ------------------------------------------------------------------------ April 22, 2005 - 14:05 : stefan nagtegaal Attachment: http://drupal.org/files/issues/drupal_set_message consistency part 1 of 2 (51.16 KB) first patch of 2 to make the drupal_set_message(), form_set_error() and watchdog() messages more consistent. please review/comment and apply..

3 2

[drupal-devel] [task] Consistent return 'passive voice' in form_set_error() and drupal_set_message()
by puregin 23 Apr '05

23 Apr '05

Issue status update for http://drupal.org/node/15595 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: stefan nagtegaal Reported by: bertboerland(a)www.drop.org Updated by: puregin Status: patch A big -1 from me on replacing "you" with "me" :) Regarding the use of the first person - I find it extremely awkward and confusing to see usage such as 'My Account', "Here are my recent posts", etc. From my perspective as a native speaker of English, I find that this kind of usage violates conventional "conversational context". To clarify, if I am communicating with another person *via* the medium of a program then I expect that person to follow the normal conventions of conversation, in particular, to say "me, my, I" when referring to him/herself, and "you, your, etc." when referring to me. If I am communicating with a program, I *also* expect it to follow conversational conventions. Particularly obsequious programs may always refer to themselves in an indirect second person: "This unworthy program was unable to execute your most excellent command, and will henceforth terminate itself" I have to say I really don't like this kind of interaction. I like a program that tells me straight up "I can't find my configuration files! Sorry, I'm giving up!" People like, understand, and are extremely good at direct conversational interaction. It's intuitively clear who is speaking and what the relation to the listener is. I might tolerate a page with title "My Account", but really, a message such as 'This page shows my site-wide referrer statistics. I can optionally view just the "external referrers" or the "internal referrers". Referrers are web pages, both local and on other sites, that point to your my site.' is just plain confusing and unclear. To quote Sendmail: "I refuse to talk to myself" Please don't inflict this gratuitous use of first person on us! Djun puregin Previous comments: ------------------------------------------------------------------------ January 14, 2005 - 05:59 : bertboerland(a)www.drop.org *My* drupal not *Yours*! I think that when one addresses the user or the administrator of a site, it is best to do this outside in instead of inside out. So when in the documentation the coder is referring to the site of the administrator, this site should be called "your site" (/inside out/) but "my site" (/outside in/). There are numours examples where the text in referring to "your"where "my"would be apopriate [1] There used to be some "your" in the userinterface for the enduser as well, but that has been solved in 4.5. Before that you had "my account", but "track your postings". This has now all beens replaced by "my"and "mine". If everybody agrees, lets also corect this for the administrator as well; my administrator, not yours ;-) [1] examples: admin/logs/referrers "...that point to your web site." admin/settings "General configuration options for your site" ------------------------------------------------------------------------ April 19, 2005 - 08:36 : stefan nagtegaal We should consistently use the 'passive voice', when returning messages using form_set_error() and drupal_set_message(). ------------------------------------------------------------------------ April 22, 2005 - 04:05 : stefan nagtegaal Attachment: http://drupal.org/files/issues/drupal_set_message consistency part 1 of 2 (51.16 KB) first patch of 2 to make the drupal_set_message(), form_set_error() and watchdog() messages more consistent. please review/comment and apply.. ------------------------------------------------------------------------ April 22, 2005 - 04:05 : stefan nagtegaal Setting status to Patch.

1 0

Re: [drupal-devel] Event changes
by Ber Kessels 23 Apr '05

23 Apr '05

> Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is. Yes. On the event sprint meeting, we agreed that an event is anything with a date. In better wording, anything that has a date as metadata, can be treated as event. Let us indeed not narrow this down to case specific (i.e. event must hold location start and end etc) events. Ber --

1 0

Re: [drupal-devel] Event changes
by Ber Kessels 23 Apr '05

23 Apr '05

Hello > Since flexinode is a very usefull and popular module, I don't think it is a problem to depend on it. I agree. And I think -in contrary to Adrians idea- that flexinode is not complex. For users, that is! When you look at the code, yes, its overly complex, but for end-users its not hard at all to use. +1 for depending on it. Ber --

1 0

[drupal-devel] [bug] Cannot delete users
by asimmonds 23 Apr '05

23 Apr '05

Issue status update for http://drupal.org/node/19750 Project: Drupal -Version: cvs +Version: 4.6.0 Component: user.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: AtomicMaestro Updated by: asimmonds Status: patch I'm reopening this for 4.6.0, as the bug still exists in the released 4.6.0 and I can't find moshe's patch being committed to the 4.6 branch. A number of people in the forum (http://drupal.org/node/20970) have also found it doesn't work as expected. asimmonds Previous comments: ------------------------------------------------------------------------ March 31, 2005 - 21:33 : AtomicMaestro I can't seem to delete users. To reproduce: 1. Create a user. 2. View the user created in 1. 3. Click Delete I would expect to be told I have to block the user first, but instead, I'm sent back to the user report. There's no message, nothing in the log. ------------------------------------------------------------------------ April 1, 2005 - 19:40 : asimmonds Attachment: http://drupal.org/files/issues/fix_delete_user.patch (581 bytes) Patch attached to fix this, the delete code in node.module works the same way ------------------------------------------------------------------------ April 4, 2005 - 02:15 : moshe weitzman when one deletes a user from list of users in admin, he expects to return back to that list after successfully deleting. thats the intent of the $_REQUEST['destination']. I think this patch will defeat that behavior. There certainly is a bug here, but I don't think we have found the right fix yet. I suggest testing a delete from both admin and user/edit pages. make sure you arrive at the expected page after a successful delete. ------------------------------------------------------------------------ April 4, 2005 - 19:19 : asimmonds There are two methods to enter the user edit page as a admin: 1/ View a user, then select the edit tab. 2/ Click 'edit' for the user in the admin/user list. The 2nd method sets destination=admin/user in the URL, when the user edit page is shown. If the Delete button is clicked, it calls drupal_goto("user/$account->uid/delete") (the code's comment mentions this is done to make the tabs disappear). As destination is already set, drupal_goto() redirects to that ie. "admin/user" instead of "user/$account->uid/delete" If after successfully deleting a user, the code calls drupal_goto("admin/user"). I looked at how node.module does the node delete/confirm sequence and it has this unset($_REQUEST['destination']) in there as well. Maybe this delete/confirm sequence pattern needs a re-think for 4.7 ------------------------------------------------------------------------ April 6, 2005 - 16:01 : moshe weitzman Attachment: http://drupal.org/files/issues/user_15.patch (1020 bytes) here is an alternative. this one properly maintains the destination parameter which is useful especially when you are not on the 1st page of your user listing. the redirect insures that you return to the page you were on. another advantage is that i was able to delete a few lines of code which were performing a drupal_goto(). the downside is that the pupose of the drupal_goto() was to get rid of the tabs. I don't mind the tabs on the delete confirm page, so I think my patch is better, and removes a couple lines of code. either patch presented here would work ok. ------------------------------------------------------------------------ April 6, 2005 - 17:13 : moshe weitzman Attachment: http://drupal.org/files/issues/menu_set_location.patch (2.23 KB) here is a different patch suggested by UnConed. Uses menu_set_location() to remove the tabs on the delete confirmation page for both nodes and users. ------------------------------------------------------------------------ April 7, 2005 - 07:28 : Dries Mmm, Steven's patch fixes the tabs but still is a bit of a hack. (Also, parts of the strings can't be translated, the use of arg(1) vs $edit['nid'] looks a bit weird.) Can't we fix this properly? ------------------------------------------------------------------------ April 9, 2005 - 00:50 : Dries Could this be fixed properly by making a stand-alone callback for the delete view? ------------------------------------------------------------------------ April 13, 2005 - 07:43 : Dries Last patch committed to DRUPAL-4-6. Still waiting for a better fix for HEAD.

1 0

[drupal-devel] [bug] there is something wrong with submission queue
by Jose A Reyero 23 Apr '05

23 Apr '05

Issue status update for http://drupal.org/node/20651 Project: Drupal Version: 4.6.0 Component: queue.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: dodobas Updated by: Jose A Reyero -Status: active +Status: patch Seems I cannot change priority to crital :-) Anyway, the status should be patch Jose A Reyero Previous comments: ------------------------------------------------------------------------ April 16, 2005 - 23:14 : dodobas well it does not work like it should. First of all there is a bug that causes following pgsql error: pg_query(): Query failed: ERROR: invalid input syntax for integer: "page" in /home/dodobas/public_html/drupal-pg/includes/database.pgsql.inc on line 45. this happens when you enable *queue* module, and try to add any kind of content by clicking on /create content/. AFAIK mysql is immune to integer related errors. Anyway after changing following line in queue.module: 238: $node = node_load(array('nid' => $id)); to 238: $node = node_load(array('type' => $id)); the query is working normally. I don't know is this what is intended for that query to do, but it fixes the problem. Other problems i just don't know how to "fix". When i finally create content and put it in moderation 'queue' displaying of posts in moderation queue is not ok. After i make a 'vote' content of submission queue does not get rendered properly. Instead of properly SUMing up the votes, and showing only one item, it shows duplicate items. And i think that the number of duplicate items depends on number of users votes, but i could be wrong... As I recall submission queue in Drupal 4.5.2 worked fine.... ------------------------------------------------------------------------ April 19, 2005 - 09:21 : dodobas Attachment: http://drupal.org/files/issues/queue_fix.patch (1.43 KB) ------------------------------------------------------------------------ April 19, 2005 - 09:26 : dodobas i forgot to explain it: 1. postgres integer problem fixed 2. multiple display of nodes in submission queue was caused by wrong group by statment also i think that queue module is still underdevloped, and can't think of a way to use it ... ------------------------------------------------------------------------ April 23, 2005 - 00:39 : Jose A Reyero Attachment: http://drupal.org/files/issues/queue_fix_plus.patch (1.75 KB) The node count for the moderation page is also wrong, Just added one more line to the patch. Changed priority to critical, as these bugs render the submission queue unusable.

1 0

Re: [drupal-devel] Let's accept more interim solutions
by K B 22 Apr '05

22 Apr '05

> * We establish a goal: e.g., within two months of opening of HEAD, we > apply or turn down 80 to 90 percent of patches that are two months or > more old (and apply some promising newer ones as well). > > * At opening of HEAD, we (e.g., a set of volunteers) review the patch > list and identify priority patches to be worked through quickly. > > * Patches from this list are applied if (a) one skilled developer (other > than the primary submitter!) affirms successful testing and (b) a week > has passed without new problems being identified. I agree with this approach. Too many good ideas are dropped on the floor. Either because the process is slow (due to lack of time from core developers or otherwise), or because we as a whole are overzealous. A decision to either accept or drop a patch must be clearly so. We cannot expect that Dries be the judge of every patch, nor can we accept a few +1 and a few -1 to be the final word. There has to be a clear Yes or No on a patch, and if No, we have to say why No clearly, and whether it is the functionality that is the issue, or the implementation (user interface, coding, security, ..etc.) This has to happen in a speedy manner, and not drag on till we have 100+ patches pending. In other cases, we remove functionality from site admins and users (e.g. the "Remember me" was taken away in 4.5) for the sake of a puritan goal: "not having too options". This goes back to a suggestion earlier (I think it was by Nedjo) of forming quasi committees to decide on patches. Drupal is growing fast, and going into many areas that we never imagined at its inception (e.g. ecommerce, ourmedia, ....etc.), the user base is growing fast, and the developers are also growing. Guys, I am not criticising anyone in particular, if anything it is self critisim of what we all are. We have done a lot of great things, and we need to adjust to the above changes in a positive way.

2 1

[drupal-devel] [feature] Additional permissions for page module
by moshe weitzman 22 Apr '05

22 Apr '05

Issue status update for http://drupal.org/node/20977 Project: Drupal Version: 4.6.0 Component: page.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Syntoad Updated by: moshe weitzman Status: patch furthmore, 'edit others x' has the same meaning as a row in the node_access table. we no longer do this sort thing via permissions. moshe weitzman Previous comments: ------------------------------------------------------------------------ April 20, 2005 - 23:21 : Syntoad Attachment: http://drupal.org/files/issues/page_perms.diff (619 bytes) I am using drupal as a semi-wiki, and wanted all users to be able to edit any page, but didn't want to allow them to administer pages (gives access to too many other things such as configuring the front page) This patch will add the permission 'edit others pages' to the page module. ------------------------------------------------------------------------ April 21, 2005 - 07:09 : Syntoad Forgot to set status to patch. ------------------------------------------------------------------------ April 22, 2005 - 11:27 : drumm This should be done in a more generic way so all node types can have consistent permissions.

1 0

[drupal-devel] [feature] Additional permissions for page module
by drumm 22 Apr '05

22 Apr '05

Issue status update for http://drupal.org/node/20977 Project: Drupal Version: 4.6.0 Component: page.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Syntoad Updated by: drumm Status: patch This should be done in a more generic way so all node types can have consistent permissions. drumm Previous comments: ------------------------------------------------------------------------ April 20, 2005 - 22:21 : Syntoad Attachment: http://drupal.org/files/issues/page_perms.diff (619 bytes) I am using drupal as a semi-wiki, and wanted all users to be able to edit any page, but didn't want to allow them to administer pages (gives access to too many other things such as configuring the front page) This patch will add the permission 'edit others pages' to the page module. ------------------------------------------------------------------------ April 21, 2005 - 06:09 : Syntoad Forgot to set status to patch.

1 0