- Development - lists.drupal.org

CCK per field CRUD settings, caching complexity
by Bèr Kessels 30 May '06

30 May '06

Hello list, I am developing some per-field CCK permissions: CRUD settings for every chunk of data. But I am still rather concerned about caching. Let us assume two roles, and three field types: Role1: child Role2: easter bunnies Field1: description, viewable by boh roles Field2: Egg color: only viewable by children Field3 Egg Location: only viewable by easter bunnies IF we add an Egg Node, we will have three virtual nodes: in DB, viewed by admins etc: descr: This Grand Foo Egg is very nice, it tastes like beer, but is made from specially, handselected Foo. color: Yellow and white. location: Bar. child looking at node: descr: This Grand Foo Egg is very nice, it tastes like beer, but is made from specially, handselected Foo. color: Yellow and white. bunny looking at node: descr: This Grand Foo Egg is very nice, it tastes like beer, but is made from specially, handselected Foo. location: Bar. So back to caching: Should we cache them as three separate nodes? This means that any combination of fields and roles will get a cache entry. with five roles and 3 fields this becomes (I forgot the math, was it 5! or 5^5 ?) a lot! The other option is to cache per role: the obvious problem occurring here is what to do with users that have more then one role. In the first example each combination of roles has an own entry. But here we would have less cahce, but more complex code to merge the various cache results, which is additional overhead, and kindof defeats the purpose of cache. So: Are there other ideas? Modules I should look at? Or do you think I am going down the wrong road? Bèr -- PGP ber(a)webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels(a)gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek

5 13

Re: [infrastructure] Re: [development] Drupal 4.5 unsupported
by Gildas Cotomale 30 May '06

30 May '06

2006/5/30, Richard Archer <drupal.org(a)juggernaut.com.au>: > At 11:02 PM -0700 29/5/06, Jonathan Lambert wrote: > > >And nobody ultimately benefits. The > >people who stay on the version end up on a "fake fork", the user > >community may get materially fragmented, the users end up with a > >"tough luck pal" response from the community for support > > This is where Drupal has real problems. Because Drupal's API > changes so radically and so often, it pretty much forces > established sites with any customizations at all to stick with > whatever version they first built their site on. > Hmm. I'm new to Drupal (i jump into it with a 4.3) and i'm not an active developer (i.e i only do my own developpement and test alot -but don't have oportunity to report a bug because those i've noticed were already submited- however, since 4.6, a part of my business -yes i'm consultant and own a web agency- is based on Drupal). I agree with the point that Drupal's API changes often, and it's a good thing.. It's a good point because this let Drupal in the competition and show an evolution of the product (being more and more mature and able to face the new needs). This has been debated many times. However, i don't agree when you say that those changes are always or often radical.. For far i know the major change was the node system the introduction of taxynomani (users can see them and love them), then now the new FAPI (i know developers do/will love it) and AJAX stuffs (this later is only cosmetic/marketing and is done the right way : inobstructive and degrade well). Those major changes were really needed, but they don't occur every morning.. In another hand, Drupal team always try to archive back compatibility ; that's not always the same with to other CMS.. And if we refuse to go ahead, we'll be in the same situation as PHP-Nuke (people will fork and do those changes and users will follow them one day or another leting us with a young-so-old baby).. Now, with time passing, users less need to interact directly with core (let this side for modules) because Drupal is becoming more and more easy and customisable (a good reason to upgrade). > And since people (at least the ones I know) expect their site > to last longer than 12 months they will inevitably find > themselves using an insecure, unsupported version of Drupal. > Drupal is a bit like Linux kernel and many FSF tools :] Old versions are not really abandonned but not official supported.. because there's no human ressource for that.. As mentionned by Dries, old versions may be updated if there are people to give them some love (essentialy patching and reviewing submited patches..). This is more than what can offer many projects at SourceForge..

1 0

shared database solutions
by John Joseph Bachir 29 May '06

29 May '06

Hello. I'm the developer of Lyceum, a blogging services system based on WordPress. I'm looking into what the state-of-the-art is for common user login/namespace/database solutions. My dream is to come up with a sustainable solution for sharing a user database between Lyceum, Drupal, and MediaWiki. What are folks using these days? LDAP? XMLRPC? Hacky custom backend scripts? Any info on this topic would be very appreciated. Thanks, John ---- aim/yim/msn/jabber.org: johnjosephbachir 713.494.2704 irc://irc.freenode.net/lyceum http://lyceum.ibiblio.org/ http://blog.johnjosephbachir.org/

5 5

how should singlesignon module handle caching
by Daniel Convissor 29 May '06

29 May '06

Hi Folks: I'm the author of the singlesignon module. It doesn't work if caching is turned on. wrunt was able to give a detailed description of what seems to be the issues at hand at http://drupal.org/node/62942 in update 1. I don't know how to best modify the module to work correctly, so request guidance from the developers here who know a lot more about how Drupal works. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

1 0

New UI for selecting project taxonomy: please clear your browser cache
by Derek Wright 29 May '06

29 May '06

at the request of killes (and others), i've changed the UI on the project node editing page regarding how you select the taxonomy terms that apply to your project. the new UI enforces that you select a single top-level term (module, theme, translation, etc) by presenting those as radio buttons. if you select "module", you can still further classify your project with the various categories of modules (administration, mail, etc) using a multi-select box. however, the new UI makes use of some changes in the project.css file, so things will look a little funny until you clear your browser cache. for the full story, see http://drupal.org/node/64221 if anyone has any trouble, please just re-open that issue. thanks, -derek (dww)

1 0

4.7 maintenance: XHTML error in generated forms
by Gerhard Killesreiter 29 May '06

29 May '06

Hi there! The last patch on this issue was committed to Drupal HEAD in order to fix the problem. I'd like to backport this to 4.7, but I am concerned that changing the ID values might break things such as CSS and JS, two areas were my knowledge is meagre. Can anybody confirm or (even better) deny this suspicion? I this is an issue is there a 4.7 compatible way to fix this for 4.7 only? Cheers, Gerhard

2 2

Re: [development] module auto installer
by Jean-Marie Renouard 29 May '06

29 May '06

Hello ;o) I am a newbie drupal ( a have just read the API and found it very clean ). It will be a very nice idea in fact. I m thinking a deeper intergration in the Drupal system. So that in the administer/Modules links described in System.module ( ?? ), a administrator can install a module without leaving the web interface. I wrote a command line script but I imagine this could be a cool feature to be able to install/search/download modules from the administration interface. Best regards, Jean-Marie Renouard 2006/5/29, Bèr Kessels <ber(a)webschuur.com>: > > Op maandag 29 mei 2006 10:24, schreef Jean-Marie Renouard: > > Hello, > > > > I have written a quick but very useful php script which acts as > 'apt-get' > > from Debian and allows administrators to install module from the web. > > > > I have post 2 messages : > > http://drupal.org/node/65374 > > http://drupal.org/node/65657 > > > > I just want to be sure that developper are aware of it. > > I propose to maintain and help integrating it in Drupal if you like. > > > > I just want to know the Drupal devellopper feelings about it. > > Looks extremely usefull. I would love to include this in Sympal Scripts, > would > you mind me doing so? > > Bèr > -- Cordialement, Jean-Marie Renouard

1 0

module auto installer
by Jean-Marie Renouard 29 May '06

29 May '06

Hello, I have written a quick but very useful php script which acts as 'apt-get' from Debian and allows administrators to install module from the web. I have post 2 messages : http://drupal.org/node/65374 http://drupal.org/node/65657 I just want to be sure that developper are aware of it. I propose to maintain and help integrating it in Drupal if you like. I just want to know the Drupal devellopper feelings about it. -- Best regards, Jean-Marie Renouard

1 0

social network module
by Albert Wong 28 May '06

28 May '06

Greetings - I don't generally post here, but I read your comment re: social networking and I didn't want it to fall through the cracks.. . so I just wanted to give you a little bit of (hopefully helpful) guidance, regarding which direction to take, in case you're looking for some. On dev / your 5.26.06 posting / it seemed as if you were trying to decide whether to go for developing either... (1) "social networking" capabilities, a la orkut -- for drupal end users -- (2) or network analysis -- for drupal admins. Personally, my vote is for polishing up the social network capabilies of drupal for end users, a la orkut. [In fact, (1) might be a prerequisite for a successful deployment of (2). Reasoning: without adequate SN capabilities, there might be little network infrastructure to analyze.] :-) Anyhow, that's my current interest and bias and in case you've elect to go that route, I've done some investigating of what drupal already has on offer, so could hopefully give you a bit of a head start. There's definitely stuff you can build on, although there's also quite a ways to go. The principal social networking tool available in Drupal, imho, currently, is Drupal's "buddylist.module" which is supposed to be the rough equivalent of the common "friends" function you find on all the popular SN sites, orkut, myspace, etc. The module is well written and well documented. So, I would consider building off of it. However, this module has two significant drawbacks, (1) First, under its current cvs setup, *buddy relations are not symmetrical*. That is, if A is buddy of B, it does not imply that B is buddy of A. That is, buddylist treats friendship relationships as *directional*, rather than *mutual*. This creates some confusing scenarios -- for example -- under the current setup, you can have the following situation: "Jack is buddies with Jill, but Jack is not buddies of Jill, where as Jill is not buddies with Jack, but Jill is buddies of Jack" [Did you get that? ;-)] Although there might be some very unusual special cases where a unidirectional friend relationship might be useful, this is clearly, generally, not the common semantic case. (2) Second, currently, *buddy relationships may be unilaterally determined*. That is, A can unilaterally decide to declare that he is buddies with B, regardless of B's consent. That is, for example: "Quasimodo, the crazy stalker, can decide *on his own* that he's buddies with Esmerelda, even though Esmerelda has placed a restraining order on Quasimodo." Again, this unilateral capability is not standard in the common usage of buddy relationships as a social networking tool - and for good reason, I believe. Generally, buddy relationships are mutually and *consensually* determined. There are other more superficial issues regarding the polishing of buddylist, but these two issues strike at the core of it, and should be tackled first, imho. A solution to these two issues above has been posted as a patch here http://drupal.org/node/11892 -- it is patch that I wrote -- with help from RobRoy -- and functions without a hitch on my site, www.ithou.org . This patch replaces the "asymmetric" / "non-consensual" framework with one that is "symmetric" and "consensual". It is still awaiting review. I imagine that you could assist in that polishing and review process and as part of your SoC contribution, you could help move Drupal and buddylist into a more solid social networking platform. Should this be of interest to you as part of your SoC project, please do not hesitate to contact me. Regards, Albert albert [at] ithou.org

1 0

Here is how you can get 4.5 security patches
by Karoly Negyesi 28 May '06

28 May '06

Hi, I am shocked by the demands to support 4.5. Do not forget that you are not paying Drupal developers to do anything. You are not my boss. Nor anyone else's. On what base do you demand? On the amount of contribution you made to Drupal over time? I have yet to see any such contributor (note: I said contributor, not coder.) who demands this. Therefore, the solution is very simple: if you are running 4.5 and do not want to update, find others in the same situation and hire an able coder who will provide the security patches for you. We will consider adding said person to the security team and some guidance will be providded, but please do not expect too much from our side. Case closed. Kind regards, Karoly Negyesi Ps. While I sometimes work for money, do not consider me. The less 4.5 code I need to touch, the better for me. Money won't change this.

9 9