Re: [development] Easter problem

[la...@garfieldtech.com]

There's no need for a hook here at all.  You can either code in the 
algorithm for defining when Easter is (which sounds like it is in fact 
rather complicated) or just pre-store know pre-calculated dates for it 
for the next decade or so.  (10 records, one per year; totally easy.)


Both options are described here, including the different mechanisms for 
defining when Easter is in different calendars:


http://en.wikipedia.org/wiki/Easter#Date_of_Easter

--Larry Garfield

On 11/30/10 1:14 PM, Ámon Tamás wrote:

Hello,

I have the nameday module (http://drupal.org/project/nameday) and I get
a feature request for the Greek namedays. How I see it is based on the
Easter, what is not an easy thing to count.

Well, I want to find some algorithm for Easter, and similar days, what
is can be stored somehow. Maybe it should be a hook or some other think
what can be stored in database.


Thanks

--
Ámon Tamás
Sitefejlesztő és programozó

Re: [development] Easter problem

[la...@garfieldtech.com]

The Calendar PHP module is not enabled by default in a stock PHP, so I 
don't know that you can rely on it (unfortunately).  It does have some 
cool stuff in it, though.


--Larry Garfield

On 11/30/10 1:22 PM, Carl Wiedemann wrote:

Does this help? http://php.net/manual/en/function.easter-days.php

On Tue, Nov 30, 2010 at 12:14 PM, Ámon Tamás mailto:am...@5net.hu>> wrote:

Hello,

I have the nameday module (http://drupal.org/project/nameday) and I
get a feature request for the Greek namedays. How I see it is based
on the Easter, what is not an easy thing to count.

Well, I want to find some algorithm for Easter, and similar days,
what is can be stored somehow. Maybe it should be a hook or some
other think what can be stored in database.


Thanks

--
Ámon Tamás
Sitefejlesztő és programozó

Re: [development] Issue priority

[la...@garfieldtech.com]

I believe this to be a good change and agree with it.  However, normally 
such changes should be discussed in the relevant issue queue before 
being made.  A note to this list telling people about the discussion 
early on is a good courtesy.


--Larry Garfield

On 1/11/11 5:59 AM, Steven Jones wrote:

Hello Drupal developers,

With automated testing, Drupal 7 has had the policy that a failing
test would be a sufficient condition for the related issue to be
marked as 'critical'. This was according to the handbook page that
describes the meaning of the issue priorities:
http://drupal.org/node/45111

However, this was not true. Drupal 7 was released with several tests
that failed, but only in the secondary testing environments notably:
PostgreSQL and SQLite on Linux. They passed in the primary testing
environment of MySQL + Linux.
I think that this is fair, but a failing test should still be given a
higher priority that other issues, so I've updated the aforementioned
handbook page so that failing tests in the secondary environments are
'Major' issues.

I've basically changed this because it makes sense to me, and because
changes to the handbook are really easy to revert. Was this the right
change to make?

Regards
Steven Jones
ComputerMinds ltd - Perfect Drupal Websites

Phone : 024 7666 7277
Mobile : 07702 131 576
Twitter : darthsteven
http://www.computerminds.co.uk

Re: [development] Drupal Answers: A Stackoverflow/StackExchange site proposal

[la...@garfieldtech.com]

Sounds like something to discuss in detail at DrupalCon Chicago and 
develop an action plan for. :-)


--Larry Garfield

On 1/31/11 5:37 PM, Randy Fay wrote:

I don't think we can delegate any part of Drupal to something we don't
control; I think that's just a non-starter.

So for me, the issue is what we can learn from StackOverflow and friends
- they do great stuff and end up with great content. And yes, I think we
should build something on that.

Who is signing up to build it? I think it's an easy sell.

-Randy

On Mon, Jan 31, 2011 at 4:25 PM, Dan Horning mailto:dan.horn...@planetnoc.com>> wrote:

i have to ask ... what would we actually gain by doing this -
cleanup the various methods for finding info about a given module or
theme or bug a little and we far surpass this suggested tool

it seems that stackoverflow is driven very highly on userpoints to
control access - which while a good thing - doesn't really fit the
development model we have here. there are existing processes that
would have to change to fit the suggested model. I for one am more
for peer reviews and leadership staff assigning access than a points
system that someone could rack up points and just get access ...
what's that really do for the community - seems that would be great
if we were just a tech help forum - awarding points for the users
that help and giving them more access - but what's that do for
drupal and it's community? (i know there is a potential for this to
help ...)

another area of issue to me is - another login ? or would it use SSO?
do the drupal leadership users and dries have admin level control...?

mostly here i just don't get what adding yet another resource (like
has been said before) would do to help the lead devs, module + theme
devs and just supporting drupal. if i had say -=- i'd vote against
this idea

--
Dan Horning

- Original Message -
 > From: "Victor Kane" mailto:victork...@gmail.com>>
 > To: development@drupal.org 
 > Sent: Monday, January 31, 2011 6:01:55 PM
 > Subject: Re: [development] Drupal Answers: A
Stackoverflow/StackExchange site proposal
 > I guess this is a good place to start:
 > http://area51.stackexchange.com/faq
 >
 >
 > On Mon, Jan 31, 2011 at 8:00 PM, Victor Kane <
victork...@gmail.com  >
 > wrote:
 >
 >
 >
 >
 > On Mon, Jan 31, 2011 at 6:57 PM, Josh Koenig <
j...@getpantheon.com  >
 > wrote:
 >
 >
 >
 > Stew,
 >
 >
 > Thanks for starting this thread. This is important stuff:
 >
 >
 >
 > http://area51.stackexchange.com/proposals/2978/drupal-answers
 >
 > I want to put my support behind this proposal and explain my thinking
 > in doing so.
 >
 >
 > The Drupal community is already growing faster than Drupal's
 > infrastructure can easily support. With the release of D7 and all the
 > other associated projects getting off the ground, drupal.org
 is
 > increasingly often a bottleneck or blocker. We have wonderful hosts
 > from OSUOSL, but the human resources needed to develop, maintain and
 > manage our own infrastructure (which is a 24x7x365 job) are limited.
 >
 >
 > We have to pick our battles. I much would rather see energy, effort,
 > attention and money poured into continuing to improve our git and
 > module infrastructure — which is much more deeply intrinsic to the
 > health and future of the project — and accept that even though we
 > *can* build our own StackOverflow (@eaton proved this already) that
 > doesn't necessarily mean it's the best use of limited resources, or
 > the best thing for the project.
 >
 >
 > Drupal can theoretically/technically solve a lot of its own problems,
 > but I think we often suffer from a "not built here" prejudice as a
 > result. In the realm of getting good quality answers to Drupal
 > questions out to the most people possible, I can't see how a
 > StackExchange site would do anything but help. I would love to
see the
 > community embrace something really cool and useful from the wider
 > Internet as a way to promote the project.
 >
 >
 >
 >
 > You make a convincing argument Josh; my own gut feeling has been,
 > reading this thread, "how can we delegate something so important to
 > the Drupal Community as its own documentation to another party
who may
 > or may not exist in the near/medium/long term".
 >
 >
 > Can someone inform somewhat on who these guys are? And why there and
 > not someplace else?
 >
 >
 > Victor
 >
 >
 >
 >
 >
 > Finally, I should say that I *do not* think a StackExchange answers
 > site re

Re: [development] Drupal Answers: A Stackoverflow/StackExchange site proposal

[la...@garfieldtech.com]

Uh, Victor, you are aware that Wikipedia has a "team" of editors who 
correct, prune, and curate content far more actively than anyone on 
Drupal.org, right?


And you are also aware that Drupal core has appointed "leads" who are 
extremely picky about what they allow in?


And that PHP itself has about 1000 committers who don't have to talk to 
each other before committing, and the result is an utter trainwreck of 
inconsistency and people committing things in the middle of the night 
just to avoid the fact that everyone else already said no to an idea? 
(True story.)


Just making sure about that...

--Larry Garfield

On 2/1/11 6:37 AM, Victor Kane wrote:

I won't be able to go to DrupalCon this year, so I'll give my feedback here.

One thing that's clear from the success of many open documentation sites
(wikipedia, stack overflow) is that they avoid top down governance, they
let the meritocracy form on the basis of what actually happens.

I firmly believe that the existence of "document leads" and other forms
of control have done more harm than good, despite heroic efforts from
these individuals, since all that has happened over the last few years
is a constant moving around of a hierarchical structure.

Why wouldn't a freer, wiki like approach work?

Victor Kane
http://awebfactory.com.ar

On Mon, Jan 31, 2011 at 8:37 PM, Randy Fay mailto:ra...@randyfay.com>> wrote:

I don't think we can delegate any part of Drupal to something we
don't control; I think that's just a non-starter.

So for me, the issue is what we can learn from StackOverflow and
friends - they do great stuff and end up with great content. And
yes, I think we should build something on that.

Who is signing up to build it? I think it's an easy sell.

-Randy


On Mon, Jan 31, 2011 at 4:25 PM, Dan Horning
mailto:dan.horn...@planetnoc.com>> wrote:

i have to ask ... what would we actually gain by doing this -
cleanup the various methods for finding info about a given
module or theme or bug a little and we far surpass this
suggested tool

it seems that stackoverflow is driven very highly on userpoints
to control access - which while a good thing - doesn't really
fit the development model we have here. there are existing
processes that would have to change to fit the suggested model.
I for one am more for peer reviews and leadership staff
assigning access than a points system that someone could rack up
points and just get access ... what's that really do for the
community - seems that would be great if we were just a tech
help forum - awarding points for the users that help and giving
them more access - but what's that do for drupal and it's
community? (i know there is a potential for this to help ...)

another area of issue to me is - another login ? or would it use
SSO?
do the drupal leadership users and dries have admin level
control...?

mostly here i just don't get what adding yet another resource
(like has been said before) would do to help the lead devs,
module + theme devs and just supporting drupal. if i had say -=-
i'd vote against this idea

--
Dan Horning

- Original Message -
 > From: "Victor Kane" mailto:victork...@gmail.com>>
 > To: development@drupal.org 
 > Sent: Monday, January 31, 2011 6:01:55 PM
 > Subject: Re: [development] Drupal Answers: A
Stackoverflow/StackExchange site proposal
 > I guess this is a good place to start:
 > http://area51.stackexchange.com/faq
 >
 >
 > On Mon, Jan 31, 2011 at 8:00 PM, Victor Kane <
victork...@gmail.com  >
 > wrote:
 >
 >
 >
 >
 > On Mon, Jan 31, 2011 at 6:57 PM, Josh Koenig <
j...@getpantheon.com  >
 > wrote:
 >
 >
 >
 > Stew,
 >
 >
 > Thanks for starting this thread. This is important stuff:
 >
 >
 >
 > http://area51.stackexchange.com/proposals/2978/drupal-answers
 >
 > I want to put my support behind this proposal and explain my
thinking
 > in doing so.
 >
 >
 > The Drupal community is already growing faster than Drupal's
 > infrastructure can easily support. With the release of D7 and
all the
 > other associated projects getting off the ground, drupal.org
 is
 > increasingly often a bottleneck or blocker. We have wonderful
hosts
 > from OSUOSL, but the human resources needed to develop,
maintain and
 > manage our own infrastructure (which is a 24x7x365 job) are
li

Re: [development] Drupal Answers: A Stackoverflow/StackExchange site proposal

[la...@garfieldtech.com]

On 2/1/11 11:07 AM, Victor Kane wrote:

On Tue, Feb 1, 2011 at 1:38 PM, la...@garfieldtech.com
<mailto:la...@garfieldtech.com> mailto:la...@garfieldtech.com>> wrote:

Uh, Victor, you are aware that Wikipedia has a "team" of editors who
correct, prune, and curate content far more actively than anyone on
Drupal.org, right?


Well, that is a relatively recent development, isn't it? Their initial
success at least was due to crowdsourcing, wasn't it? Can you prove they
are doing better as a result?

Victor


That depends on your metric for "better".  My point is that 
crowd-sourcing does not inherently imply "total and utter lack of 
organization or curation".  That is what we call "uncontrolled chaos", 
and the only good thing that has ever produced is an incentive to form 
at least some structure so as to avoid it.


--Larry Garfield

Re: [development] Drupal Answers: A Stackoverflow/StackExchange site proposal

[la...@garfieldtech.com]

You're not confused, David.  I don't think anyone was proposing a Drupal 
SO to replace the handbooks, just potentially the forums.


Talking about Docs at all was an unnecessary tangent, and since it's 
never going to not have someone curating it (since a lack of curation 
and organization is, as I said previously, a bonehead idea that no one 
actually tries for more than a week on any reasonably sized effort) it's 
not worth getting upset over.  I don't quite know how we got off onto 
that tangent, but we should probably get off of it quickly. :-)


--Larry Garfield

On 2/1/11 3:34 PM, David Metzler wrote:

I'm confused... I didn't think StackOverflow was being discussed as a
replacement to handbook pages/docs.  I thought it was being discussed as
a place to get questions answered, that is support? How to glue modules
together to get a task done?

I admit to being confused about where I should put my module
documentation, but that's documentation, and I don't think that a tool
like StackOverflow would be a suitable replacement for the Handbook
sites, but maybe I've missed the whole point of this thread.

I was advocating for "whoever actually does the work" (i.e. volunteers
their time) having a larger voice than those who just aren't happy with
the way the work is being done, and want to change it.  That's not an
appointed team, and that analogy would still hold true on a site like
wikipedia.  I was just pointing out that the people who actually answer
the questions are the most valuable resource we have and should be
driving the discussion.

Hmmm I thought I was chiming on on a proposal to move much of the
kinds of things that happen in the support forums over to StackOverflow,
but it's pretty clear I've unintentionally hit some kind of nerve here
regarding your dissatisfaction with the documentation team.

Didn't mean to offend

Dave

On Tue, Feb 1, 2011 at 7:50 AM, Victor Kane mailto:victork...@gmail.com>> wrote:

On Tue, Feb 1, 2011 at 11:52 AM, David Metzler mailto:metzler...@gmail.com>> wrote:

Likewise although I already have to some extent:


first non-sequitur:

I think we have a pretty free / wiki like approach in place
already.  I also think that this is something that's best
decided by those who are doing the work.


wot? So if it's a free / wiki  like approach, leave it alone, there
are no decisions to make. Maybe some occasional pruning or abuse
control, but that should be it.

and then again:

Seems like those that are up for doing the work should have the
loudest voice here.


This is the whole problem to the approach up till now: the
documentation should not be organized top-down: this model has shown
itself to be a failure. Everyone should be contributing to the
Drupal Handbook documentation, and to the extent they do, they are
having the loudest voice. There's no need for a "team" to exist on
top of that.

All they do is move stuff around so it's harder to find. Or take
valuable Drupal 6 stuff out.

Victor


Dave

On Feb 1, 2011, at 4:37 AM, Victor Kane wrote:


I won't be able to go to DrupalCon this year, so I'll give my
feedback here.

One thing that's clear from the success of many open
documentation sites (wikipedia, stack overflow) is that they
avoid top down governance, they let the meritocracy form on
the basis of what actually happens.

I firmly believe that the existence of "document leads" and
other forms of control have done more harm than good, despite
heroic efforts from these individuals, since all that has
happened over the last few years is a constant moving around
of a hierarchical structure.

Why wouldn't a freer, wiki like approach work?

Victor Kane
http://awebfactory.com.ar 

On Mon, Jan 31, 2011 at 8:37 PM, Randy Fay mailto:ra...@randyfay.com>> wrote:

I don't think we can delegate any part of Drupal to
something we don't control; I think that's just a non-starter.

So for me, the issue is what we can learn from
StackOverflow and friends - they do great stuff and end up
with great content. And yes, I think we should build
something on that.

Who is signing up to build it? I think it's an easy sell.

-Randy


On Mon, Jan 31, 2011 at 4:25 PM, Dan Horning
mailto:dan.horn...@planetnoc.com>> wrote:

i have to ask ... what would we actually gain by doing
this - cleanup the various methods for finding info
about a given module or theme or bug a little and we
far surpass this suggested tool

it seems that stackoverflow is driven very highly on
userpoints to control access - which whil

Re: [development] Git best practices for client codebases

[la...@garfieldtech.com]

I think the question is more about non-custom dev history; there's 
little need for a client site to have the complete development history 
of Drupal 4.3 in its repo, for instance.


Lately, what I've been doing/advocating is using Drush and real releases 
to download stuff from Drupal.org (core, contrib modules, etc.) and then 
checking the whole site into Git.  If I update a module, I use Drush for 
that and then update the code in my Git repo.  Then deploy to production 
using *my* git repo (which has my full dev history but not every commit 
in every one of my projects ever) and tags.


That keeps me on real releases, avoids unnecessary repository bloat, but 
still gives me a full history of all work on that project specifically.


--Larry Garfield

On 3/1/11 1:56 AM, Sam Boyer wrote:

I tend to advocate full clone. You're talking about a task that version
control is designed for. Now that we've made the switch, IMO native
code:Git::bytecode:another VCS, or worse, patch stacks, etc. I don't
know what drush did before to "make this easy" - maybe pop off patch
stacks, update the module, then re-apply the patches? Fact is, though,
nothing Drush could have done under CVS can compare to patching with
native Git commits: your patches can speak the same language as upstream
changes, and you have all of Git's merge&  rebase behavior at your
fingertips to reconcile them.

There are some occasional exceptions to this, but I really do think it's
a bit daft not to keep the full history. Keeping that history means
peace of mind that your patches (now commits) can be intelligently
merged with all changes ever made to that module for all time, across
new versions, across Drupal major versions...blah blah blah. Trading a
few hundred MB of disk space for that is MORE than worth it.

cheers
s

On 2/28/11 10:56 AM, Marco Carbone wrote:

Since a Git clone downloads the entire Drupal repository, the Drupal
codebase is no longer so lightweight (~50MB) if you are using Git,
especially as if you clone contrib module repositories as well.

With CVS, our usual practice with clients was to checkout core and
contrib using CVS, so that we can easily monitor any patches that have
been applied, so that they wouldn't be lost when updating to newer
releases.  (Drush makes this particularly easy.) This is doable with Git
as well, but now there seems to be the added cost of having to download
the full repository. This is great when doing core/contrib development,
but not really necessary for client work. This is unavoidable as far as
I can tell, but I don't think I'm satisfied with the "just use a tarball
and don't hack core/contrib" solution, especially when patches come into
play.

Is there something I'm missing/not understanding here, or does one just
have to accept the price of a bigger codebase when using Git to manage
core/contrib code? Or is managing core/contrib code this way passe now
that updates can be done through the UI?

-marco

Re: [development] Git best practices for client codebases

[la...@garfieldtech.com]

Yeah, I don't patch core often enough to need an elaborate patch 
management system. :-)  Just checking patch files that are clearly named 
into the repo is usually fine.


--Larry Garfield

On 3/1/11 10:30 AM, Marco Carbone wrote:

"That keeps me on real releases, avoids unnecessary repository bloat,
but still gives me a full history of all work on that project specifically."

Well, svn or whatever VCS one is already using could be used this way as
well. And it doesn't really address the issue about managing patches,
which probably means that you either don't apply them (I doubt that), or
you avoid overwriting them by careful management (a patches directory or
careful monitoring of commit logs). But it's true that we aren't in the
Wild West days of Drupal 4.7/5 anymore where core patches were more
common than not, and so perhaps manual management is perfectly
reasonable, and worth avoiding the ball and chain of storing every
Drupal commit ever.

-marco

On Tue, Mar 1, 2011 at 11:13 AM, la...@garfieldtech.com
<mailto:la...@garfieldtech.com> mailto:la...@garfieldtech.com>> wrote:

I think the question is more about non-custom dev history; there's
little need for a client site to have the complete development
history of Drupal 4.3 in its repo, for instance.

Lately, what I've been doing/advocating is using Drush and real
releases to download stuff from Drupal.org (core, contrib modules,
etc.) and then checking the whole site into Git.  If I update a
module, I use Drush for that and then update the code in my Git
repo.  Then deploy to production using *my* git repo (which has my
full dev history but not every commit in every one of my projects
ever) and tags.

That keeps me on real releases, avoids unnecessary repository bloat,
but still gives me a full history of all work on that project
specifically.

--Larry Garfield


On 3/1/11 1:56 AM, Sam Boyer wrote:

I tend to advocate full clone. You're talking about a task that
version
control is designed for. Now that we've made the switch, IMO native
code:Git::bytecode:another VCS, or worse, patch stacks, etc. I don't
know what drush did before to "make this easy" - maybe pop off patch
stacks, update the module, then re-apply the patches? Fact is,
though,
nothing Drush could have done under CVS can compare to patching with
native Git commits: your patches can speak the same language as
upstream
changes, and you have all of Git's merge&  rebase behavior at your
fingertips to reconcile them.

There are some occasional exceptions to this, but I really do
think it's
a bit daft not to keep the full history. Keeping that history means
peace of mind that your patches (now commits) can be intelligently
merged with all changes ever made to that module for all time,
across
new versions, across Drupal major versions...blah blah blah.
Trading a
few hundred MB of disk space for that is MORE than worth it.

cheers
s

On 2/28/11 10:56 AM, Marco Carbone wrote:

Since a Git clone downloads the entire Drupal repository,
the Drupal
codebase is no longer so lightweight (~50MB) if you are
using Git,
especially as if you clone contrib module repositories as well.

With CVS, our usual practice with clients was to checkout
core and
contrib using CVS, so that we can easily monitor any patches
that have
been applied, so that they wouldn't be lost when updating to
newer
releases.  (Drush makes this particularly easy.) This is
doable with Git
as well, but now there seems to be the added cost of having
to download
the full repository. This is great when doing core/contrib
development,
but not really necessary for client work. This is
unavoidable as far as
I can tell, but I don't think I'm satisfied with the "just
use a tarball
and don't hack core/contrib" solution, especially when
patches come into
play.

Is there something I'm missing/not understanding here, or
does one just
have to accept the price of a bigger codebase when using Git
to manage
core/contrib code? Or is managing core/contrib code this way
passe now
that updates can be done through the UI?

-marco

Re: [development] Git best practices for client codebases

[la...@garfieldtech.com]

Unless there's something new in the packager I've not seen yet, using 
d.o pulls in production bypasses the packager.  That is, you're then 
missing:


- The full version information in the info file, which is used by update 
manager.

- The License.TXT file that every module is supposed to have.

Is that no longer the case?  I'm pretty sure both of those still only 
happen with a tarball, so if you want those (and I do) then you need to 
use a tarball.


Also, if you want to manage both core and contrib modules that way it 
means you are now using git submodules, which it's generally agreed suck 
AFAIK, or complex sub-tree merging that is out of reach of 99% of 
developers.  Hell, I've done it and I don't want to do it. :-)


Shallow clones are fine for removing disk size, certainly.  But there's 
workflow considerations there that I don't believe Git solves (at least 
not yet).  If I'm not doing site-specific or company-specific branches 
of core or modules (that is, hacking core or hacking modules, which is a 
no-no in 95% of cases), then the extra patch-level control that the more 
complex all-Git approach would allow is useless because I'm not even 
using it.


I'm not saying there are no use cases for an all-git-all-the-time site 
building process, just that it has implications that you're glossing 
over in return for a benefit that the majority of use cases don't even need.


--Larry Garfield

On 3/1/11 12:38 PM, Sam Boyer wrote:



On 3/1/11 8:13 AM, la...@garfieldtech.com wrote:

I think the question is more about non-custom dev history; there's
little need for a client site to have the complete development history
of Drupal 4.3 in its repo, for instance.


So you do a shallow clone that skips irrelevant branches and only grabs
recent history on the ones you want, that's fine.



Lately, what I've been doing/advocating is using Drush and real releases
to download stuff from Drupal.org (core, contrib modules, etc.) and then
checking the whole site into Git.  If I update a module, I use Drush for
that and then update the code in my Git repo. Then deploy to production
using *my* git repo (which has my full dev history but not every commit
in every one of my projects ever) and tags.


...which is *exactly* what I'm saying is pointless. Why stick a stupider
intermediary - tarballs - into a system that's already highly capable of
doing patch&  vendor management? The only thing you've accomplished is
diluting the capabilities of your version control system to manage
upstream changes.



That keeps me on real releases, avoids unnecessary repository bloat, but
still gives me a full history of all work on that project specifically.


"Unnecessary repository bloat?" Two great words there, let's address
each one:

"Unnecessary": well, the full branch history is a requirement if you
want to use git's smart merging algorithms. So the only way it's
"unnecessary" is if you prefer manually hauling chunks out of
patch-generated .rej and .orig files.

"Bloat": Really, step back and think about this. Are you solving a real,
compelling problem faced by most modern servers? How much does it matter
that your Drupal tree is, say, 70MB instead of 700MB? It really doesn't.
Not even on shared hosting. And, let's not forget - judicious use of
shallow clones&  compression whittles that number way, WAY down. IMO,
ripping out the vendor history is something a lot of us got in the habit
of doing because we were used to having CVS vendor data that earned us
nothing but headaches, and it was an easy "optimization" that made our
Drupal trees feel more svelte.

Well, now it does get you something. It gets you a _ton_. Now, all you
need for company-specific or site-specific customizations that can
easily coexist with rich vendor data is some branch naming conventions
and practice with reading git logs. Yeah, that takes some learning too,
but it's worth it.

cheers
s



--Larry Garfield

On 3/1/11 1:56 AM, Sam Boyer wrote:

I tend to advocate full clone. You're talking about a task that version
control is designed for. Now that we've made the switch, IMO native
code:Git::bytecode:another VCS, or worse, patch stacks, etc. I don't
know what drush did before to "make this easy" - maybe pop off patch
stacks, update the module, then re-apply the patches? Fact is, though,
nothing Drush could have done under CVS can compare to patching with
native Git commits: your patches can speak the same language as upstream
changes, and you have all of Git's merge&   rebase behavior at your
fingertips to reconcile them.

There are some occasional exceptions to this, but I really do think it's
a bit daft not to keep the full history. Keeping that history means
peace of mind that your patches (now commits) can be intelligently
me

Re: [development] node_load using cck fields

[la...@garfieldtech.com]

You can only load nodes in D6 individually by ID.  However, you can run 
raw SQL queries to find nodes meeting certain criteria, then run 
node_load() on those IDs.  I forget the functions off hand but there is 
a magic incantation to get the right field column info and build a query 
string yourself.


That said, if you're going to be displaying the node(s) then just use 
Views.  It will take much less time and be much more stable, and offer 
better theming options.


In Drupal 7, you'd either use Views or the new EntityFieldQuery.

--Larry Garfield

On 3/22/11 11:40 AM, Lluís Forns wrote:

I want to load a node using cck fields instead of nid or core fields.

Is there a "no-sql" way of doing this? I have read that maybe I could
achieve it using views, but I think it would be an overkill.

What I want to achieve is something like this:

 $inscripcio = node_load(array(
 'type' =>  'inscripcio',
 'field_alumne' =>  $nid_alumne,
 'field_convocatoria' =>  $nid_convocatoria,
 ));

any hint?

If I could get which tables use a cck type and how to join them, maybe
I could code a "generic" way to do this, so if cck-type is changed,
there is no problem.

Re: [development] Database / SQL future thoughts

[la...@garfieldtech.com]

Karoly Negyesi wrote:

There would have to be some significant performance improvements to justify
pushing these views into the database in this developers opinion.


If my understanding is correct then that's what David Strauss'
materialized views do.


Eh, not really.  They're a sort of manual optimization and re-indexing 
using data duplication.  Ideally the database should be able to do that 
internally on its own.  Most don't.


MVs are not moving the hard work of Views.module to the database. 
They're moving the hard work of the database to cached user code.


If MySQL had built-in materialized views, then we could push the hard 
work on to the database and it would do that sort of pre-generation 
itself.  Sadly it doesn't, so its "views" are really just syntax nicety.


--Larry Garfield

Re: [development] Proposed Apocrypha

[la...@garfieldtech.com]

Ivan Sergio Borgonovo wrote:


At least in my experience a "what if they were 3" makes a huge
difference to avoid 2 just a special case of 1.
But anyway how could you plan or even think an API could be
useful knowing just 2 use-case?
But then... when you cut and paste more than once... you need an
API ;)
3 is the magic number!


3 is ideal.  Two markedly different implementations can also suffice, 
for certain definitions of "markedly".  (DBTNG was good with MySQL and 
Postgres, with an eye toward Oracle.  It's better with SQLite, which 
forced some heavy rethinking that ended up making a much cleaner 
implementation without changing the API.)



And three cheers for Crell's Law and Eaton's Corollary.


I would extend that cheers further than just for the Law
and the Corollary.

BTW Ernie that`s called delegation and everybody know that
delegation is the solution to all CS problems.


There is no problem in computer science that cannot be solved by adding 
another layer of indirection (except micro-performance).


--Larry Garfield

Re: [development] need a standard for contrib node build_mode constants

[la...@garfieldtech.com]

Peter's suggestion may work for D6, but for D7, I refer people to 
Eaton's "How to make good APIs" session from DCDC.  Digest version: If 
you expect people to extend your list of flags/constants/modes, for the 
love of god use strings, not ints.  Ints WILL break.  Don't be stupid, 
use strings.


So it sounds like if we expect people to extend the build modes from 
contrib, then core should switch from ints to strings anyway.  Who wants 
to roll the patch? :-)


--Larry Garfield

Peter Wolanin wrote:

The reason I was suggesting sticking with ints is that strings are
cast to int 0 during comparison:

php -r"var_dump('cck' == 0);"

bool(true)

And core has code like:

modules/upload/upload.module:363:  if ($node->build_mode == NODE_BUILD_RSS) {

modules/book/book.module:710:if (!empty($node->book['bid']) &&
$node->build_mode == NODE_BUILD_NORMAL) {

So if CCK is using ints, that's a potentially serious bug - 0 is
NODE_BUILD_NORMAL, so I think any string build modes will basically
end up being this mode.

-Peter

On Sat, May 16, 2009 at 11:50 PM, Earl Miles  wrote:

Peter Wolanin wrote:

When doing some cleanup of my Modr8 module, I wanted to define a new
build_mode for use by
http://api.drupal.org/api/function/node_build_content/6

I believe there is no need to stick with ints; CCK uses this and I think
it's using strings.

Re: [development] Status update: WYSIWYG support in Drupal core

[la...@garfieldtech.com]

Naheem Zaffar wrote:
I think many people will be happy with a(n easily 
customiseable/extendable) tag editor in core - even those who want a 
full fledged wysiwyg, if their only other option is no editor in core at 
all.


I myself prefer a simple  tag editor too - it also has this "ability" to 
strip out all the extra markup when copying and pasting from word...


Ofcourse most developers, if asked for an opinion will choose the editor 
they like and personally prefer to be the one that is included in core, 
but that cannot happen, so what is probably needed is someone to lead 
the effort. Someone who has buy in with the developers to decide "This 
is the editor that we want in. Either it gets in or nothing" and after 
that point, I suspect most of the bike shedding will be less common and 
people may try to work on the actual issues to get that to happen.


It's not that simple.

I have build sites for "clients" where we installed a WYSIWYG and it was 
good.


I have built sites for "clients" where we installed a tag editor or 
wiki-style input filter, and it was good.


I have built sites for "clients" where we gave them just the plain 
textarea and let them write tags themselves, and it was good.


And I have sites where I would want to do a little of each for different 
textareas.


Bottom line:

Those who say that we have no need for a WYSIWYG editor and we shouldn't 
bother with it (whatever the justification given) are wrong.  Flat out, 
unequivocally, wrong.  Period.


Those who insist that we need a WYSIWYG editor in core by default so 
that it's always available are also wrong.  Flat out, unequivocally, 
wrong.  Period.


Drupal is a flexible multi-purpose tool, and in some use cases a fancy 
schmancy editor is absolutely critical.  In others it would totally 
destroy the usability of the site.


So what are we supposed to do with that?  What we should always do when 
faced with that sort of dilemma: Make it as dead-simple to extend and 
customize as humanly possible.  I want to be able to change between a 
heavy WYSIWYG of my choice, a tightly filtered set of manual HTML tags, 
an liberal set of manual HTML tags, a wiki-style syntax, and absolutely 
plain text only input... *per text area, per user, per user preference*, 
for multiple combinations of those.  Why?  Because I have run into use 
cases for every single one of those, in both personal and professional 
work.  That's what we need to be building toward.  The WYSIWYG API 
module is a very good step in that direction but it's not there yet; 
Think of this as the Filter system TNG, which desperately needs someone 
who can champion and drive that the way that the Menu API, DBTNG, and 
the D7 usability work does.  And it goes deep enough that it's something 
that has to happen in core, especially now with Fields in core.


If we don't think holistically like that, we end up with the body field 
teaser splitter button...  A major WTF usability fail that has exactly 
one use case (blogs by people who can't write an HTML comment) that is 
one of the key reasons why Palantir does not use the core body field, 
ever.  It's broken by the flawed concept that there is One True Input 
Workflow, which is simply not true.


Yours is not the only use case or workflow that Drupal needs to support. 
 Whoever you are or whatever your use case, that statement still holds 
true.


--Larry Garfield

Re: [development] Convince Client to Release Code

[la...@garfieldtech.com]

As others have noted, the time to be having this conversation with a 
client is before any work is done, not after.  Your contract (which you 
want to have, period, even if it's a friend, and this is why) should 
specify who holds the copyright on any code written for the project.


For Drupal modules, whoever holds the copyright is required to 
distribute it under the GPL... *if* they choose to distribute it.  There 
is no legal requirement in the GPL that any of the code you write ever 
be given to anyone but you and the client, just that if one of you does 
so that it is under the GPL.


Most sites include some widely-used general purpose modules, some fringe 
special purpose modules (either custom written or not), and some 
site-specific one-off code that, while still GPL, is really not useful 
to anyone else.  How much of each varies widely with the site.  There's 
really no value to distributing the latter, and I'd argue that putting 
that on Drupal.org is a net-negative as it just inflates the number of 
modules and eats up valueable namespace.  So any code that is not 
generalizable you shouldn't bother distributing anyway.


For any code that is generalizable, I think the most persuasive argument 
is that, especially for a hosted solution like you describe, *code is 
not what differentiates him in the market*.  It's the service he offers. 
 Code is incidental to that.  If people want to replicate his service 
and compete with him, replicating his service will be harder than 
replicating his code.


If the code is not that important to the service, then he loses nothing 
by releasing it.  If that particular functionality is that important to 
the service, then someone else trying to compete with him will replicate 
the code that provides the functionality, release it, get the karma and 
good will of doing so, which means the free support and increased 
likelihood that someone will answer questions when he has them, etc. 
The free, shared version of that functionality will eventually become 
better than whatever your client's hidden version is, so his competition 
will have *better* code at their disposal than he will, and he'll be 
stuck with code that no one can support except him that is worse than 
the publicly available, shared version.  That's the worst possible 
situation for him to be in.


Sometimes, releasing code does help your competition.  Any Drupal 
consulting shop that releases modules or makes patches to existing 
modules is directly benefiting other consulting shops that they may end 
up bidding against on a client.  And those shops are doing the same in 
return.  With enough shops doing that (and there are), you're still 
getting more free code and functionality than you're giving away. 
Everyone is perpetually in "code debt" to the larger community in terms 
of code given away vs. code gotten for free.  It also means that other 
module maintainers are more likely to consider your feature requests and 
patches (even if they have to write them themselves) if they recognize 
you as an active contributor.  That's what makes open source work; 
everyone is in debt to everyone. :-)


Fred Jones wrote:

We have one client for whom we wrote a set of custom modules. I asked
the client if we could put the modules on d.o and he balked. I tried
to explain that he'll get good testing and also bug fixes and new
features maybe, if others post patches etc.

He feels that he (his organization that is) paid for the work and why
should someone else now benefit? He also has this idea that other
organizations like his will want a site like his and he has plans to
provide a hosted service for them (while this idea may seem
far-fetched, I do think he has some connections which might make this
idea feasible).

So he thinks if we release the code, then they will just grab the code
and use it. I tried to explain that your average layman has no idea
what Drupal is, no way to figure out your site is running Drupal, and
if even he got that far, he has no way of building his site without a
professional to put the pieces together (after they figure what those
pieces are of course), and then they he would do just as well to use
our hosted plan!

But he hasn't accepted this. Are there any good arguments we can use
to persuade him? I feel he has nothing to lose in releasing the code,
but we have to convince him of that.

Thanks.

Re: [development] Files table includes file_directory_path

[la...@garfieldtech.com]

sites.php was actually added specifically for this sort of issue, 
because the sites/ directory structure was too brittle.


Of course, for the files directories in particular I have long since 
dropped using sites//files in favor of files/, which 
sidesteps the issue entirely.  That doesn't need to change no matter 
what server the site moves to.


Khalid Baheyeldin wrote:
As others said, you either use symlinks (which forces you to have two 
directories per site), or the new sites.php feature of Drupal 7.


Using that, you can have a contrived name for each site (even site1, 
site2, or an md5 hash for each site), and redirect the site in it.


The trick is to not use sites/default for each site from now on, and 
only use a unique identifier. That identifier can be the same when you 
develop the site, and remains the same when you deploy the site.


On Thu, Jul 16, 2009 at 9:50 AM, Ashraf Amayreh > wrote:


Storing a file's path which may change in the future inside the
database is a bug no matter what the use case is.

I had once developed a site and then decided to move the files from
sites/default/ to sites// in order to create a new site
using the same installation and was very surprised at seeing this
bug. The path is stored in the files and users table (for profile
pics) I believe.


On Thu, Jul 16, 2009 at 1:15 AM, Kathleen Murtagh
mailto:kathl...@ceardach.com>> wrote:

On Wed, Jul 15, 2009 at 5:54 PM, Bevan Rudge
mailto:be...@civicactions.com>> wrote:

At CivicActions we have a tool (pushdb --xFix) that fixes
the paths in
the files directory and elsewhere in the db, which we run
when copying
an instance of the site to a staging environment.  However this
approach is becoming unsustainable and we are considering
using a
separate instances of Drupal core in each and every staging
environment so that they all use sites/default.

What this means is that much of the time this featurebug is
such a
PITA that Drupal's multisite features don't work for staging
environments.  In my own sandbox I don't use multisite for
staging
environments at all, because of this issue,  Do others?


I don't use multisite for managing dev, staging and production
environments.  In my workflow, it would be *more* complicated to
use this method.  I put the entirety of Drupal core into version
control and deploy working spaces straight from version
control.  This makes it much easier to control exactly what and
when code is pushed to production, and enable the ability
navigate through the history to find sources of bugs.

The only time I use multisite is for actual separate, yet
integrated websites.  The most common use for me are multiple
websites that share tables, like the user-related tables.




-- 
Ashraf Amayreh

http://aamayreh.org




--
Khalid M. Baheyeldin
2bits.com , Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci

Re: [development] Files table includes file_directory_path

[la...@garfieldtech.com]

Earnie Boyd wrote:

Quoting Clemens Tolboom :


On Thu, 2009-07-16 at 10:18 -0500, la...@garfieldtech.com wrote:

sites.php was actually added specifically for this sort of issue,
because the sites/ directory structure was too brittle.

Of course, for the files directories in particular I have long since
dropped using sites//files in favor of files/, which
sidesteps the issue entirely.  That doesn't need to change no matter
what server the site moves to.


What is your sitekey structure in case of a multi-site environement and
what when doing a staging scenario ie move production to a demo of
regression environment?

(With D5 multisite I moved from the files/ to
sites//files to get rid of painfull all at once D5 updates.)




Thank you for this rebuttal of Larry's suggestion.  Larry, with your 
layout of files/ how do you upgrade one site at a time?


How do you upgrade one site at a time on any other multi-site?  Yep, 
same way.


As I said, Drupal doesn't care where the files directory is, as long as 
it doesn't change part way through the site's life time.


--Larry Garfield

Re: [development] How could everyone win and get Views in Drupal 8?

[la...@garfieldtech.com]

Um.  hook_query_alter() went into core nearly a year ago as part of 
DBTNG.  It only applies to dynamic SELECT queries, which is a small 
minority of the queries Drupal runs.


Jamie Holly wrote:
Yeah I agree we really need to keep Drupal lean. I wouldn't want to see 
the entire Views package integrated as-is. I wouldn't mind some of the 
functionality included though that would give an easy way to alter some 
core queries. One that comes to mind is the comment query. Sometimes 
there are needs for extra data from the user table to be pulled in, and 
currently there really isn't an easy way to alter that query in 
comments.module.


I've thought in the past about a hook_query_alter, but that could really 
add some overhead - especially on sites with a large number of queries.


Jamie Holly
http://www.intoxination.net http://www.hollyit.net



Earnie Boyd wrote:

Quoting Jamie Holly :

> I really like that whole idea. Then we could have handy hooks to  > 
easily modify those queries if someone wishes, like maybe an easy  > 
way to add index hinting.

>

But we can have those hooks maintained in a contrib module as well.   
We just need to have a api.contrib.drupal.org or  
drupal.org/contrib/api.  I am with the crowd of keep Drupal core 
lean.The less optional modules Drupal has to consider the better 
it would  be.


--
Earnie
-- http://r-feed.com/   -- http://for-my-kids.com/
-- http://www.4offer.biz/   -- http://give-me-an-offer.com/



  

Re: [development] How could everyone win and get Views in Drupal 8?

[la...@garfieldtech.com]

Docs have been here for the past 11 months:

http://drupal.org/node/310069

Or track me down in Paris, as I fully expect to spend most of the code 
sprint(s) helping people with upgrades.


Jamie Holly wrote:
Learn something new every day! I haven't started playing with D7 yet, 
but I can see that becoming a very handy hook.


By the way, do you have a decent reference to the new Database layer for 
D7? I got some stuff to start converting and I would like to start that 
in the near future.


Jamie Holly
http://www.intoxination.net http://www.hollyit.net



la...@garfieldtech.com wrote:
Um.  hook_query_alter() went into core nearly a year ago as part of 
DBTNG.  It only applies to dynamic SELECT queries, which is a small 
minority of the queries Drupal runs.


Jamie Holly wrote:
> Yeah I agree we really need to keep Drupal lean. I wouldn't want to 
see > the entire Views package integrated as-is. I wouldn't mind some 
of the > functionality included though that would give an easy way to 
alter some > core queries. One that comes to mind is the comment 
query. Sometimes > there are needs for extra data from the user table 
to be pulled in, and > currently there really isn't an easy way to 
alter that query in > comments.module.
> > I've thought in the past about a hook_query_alter, but that could 
really > add some overhead - especially on sites with a large number 
of queries.

> > Jamie Holly
> http://www.intoxination.net http://www.hollyit.net
> > > > Earnie Boyd wrote:
>> Quoting Jamie Holly :
>>
>> > I really like that whole idea. Then we could have handy hooks to  
> >> easily modify those queries if someone wishes, like maybe an 
easy  > >> way to add index hinting.

>> >
>>
>> But we can have those hooks maintained in a contrib module as 
well.   >> We just need to have a api.contrib.drupal.org or  >> 
drupal.org/contrib/api.  I am with the crowd of keep Drupal core >> 
lean.The less optional modules Drupal has to consider the better 
>> it would  be.

>>
>> -- >> Earnie
>> -- http://r-feed.com/   -- http://for-my-kids.com/
>> -- http://www.4offer.biz/   -- http://give-me-an-offer.com/
>>
>>
>>
>>  
  

Re: [development] Why I don't Upload a Module to Drupal

[la...@garfieldtech.com]

Hi Sam.

Most sites have custom code that doesn't get released.  Generally I 
would split it into 3 groups:


- Non-module site specific stuff (like custom form alters to tweak 
something here or there).  There's really no way or reason to release this.


- Site-specific modules that are modules in their own right but really 
not useful to anyone else.  These are also generally not worth releasing.


- New custom modules that have general applicability.  It's generally 
good to release these, but not all of them do get released.


As far as support goes, the amount of time required varies widely.  If 
it's a module that requires a lot of effort to support, you could always 
get a co-maintainer to help with it.  If it's a module that you are 
going to use on later client sites, you can arguably bill them for any 
relevant time you spend enhancing or bug fixing the module.  (What 
qualifies as "relevant" is between you and the client.)


Plus, having a few modules under your belt that you can refer to can be 
good marketing for yourself and your services, as well as in raising 
your Drupal ecosystem profile which can help in getting support later, 
so you can look at it as an investment in your future business development.


I'd say it's worth your time to release modules that you think would be 
generally useful on later projects that you develop.  That's a 
reasonable gage of whether or not they're useful to others as well, and 
worth the time to share.  Remember that you can also end up with free 
features added by others, too, so it can save you time down the road.


Sam Polenta wrote:

I have made a few custom modules for clients. Some of them maybe other
people would want. I would be happy to give them to whoever wants
them, BUT it's not necessarily so simple as that.

Mostly they have some customization for the particular site so I would
have to generalize them like with a settings page etc. Then I would
have to clean up the code a bit. Some would need an install and
uninstall routine which I didn't do because it's only for one site
anyway.

I would be happy even, in theory, to release them on drupal.org but
aside from the time to prepare them, which I don't really have, I also
don't have time to support them. So I figure even if I did fix it up a
bit and put it online, I am then expected to support it. I am not a
lazy person nor do I just suck the blood of everyone else who
contributes to Drupal without giving back. I do try to help people on
the forums a bit and the truth is that I help to "make the world a
better place" in other ways. I volunteer at a local NPO to help
people--when I sit down at the computer, it's mostly to work. I need
to make a living and this is how I do it.

So I don't think I'm a total pig--not at all really because I do
volunteer my time, but just for other causes aside from Drupal.

Do people think my reasons are wrong for not releasing my code? I
guess the main thing is that I'm not prepared to support any issues or
requests etc. that may come up.

Thanks.

Re: [development] Guidelines for writing efficient SQL code

[la...@garfieldtech.com]

This is a moot point anyway as of Drupal 7, as you shouldn't be quoting 
anything.  You should be using placeholders/prepared statements for all 
queries, and the database will deal with it.


--Larry Garfield

Pierre Rineau wrote:

All I'm asking is Standard SQL, I don't blame you to use MySQL.

Pierre.

On Wed, 2009-08-26 at 10:34 -0400, Nancy Wichmann wrote:

Pierre Rineau wrote:

If you test a integer field, use no quotes, if you test a varchar field,
use quotes, that's it. Your DBMS will be smarter than you (except MySQL,
but for kitten sake, do standard SQL, it will be easier for PostgreSQL
user like me to port your code if needed).

Then why, Pierre, is the quoted version faster, by far?  At least in MySql.

Please stop disparaging MySql. The vast majority of sites use it, so it
can't be all bad.

Nancy E. Wichmann, PMP

Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King,
Jr.

Re: [development] code coverage sept

[la...@garfieldtech.com]

The reporting seems a bit wonky.  It's returning a "we didn't test this" 
for the closing brace of dozens of methods even though there's a return 
statement immediately before it, with no code in between. :-)  That's 
throwing off the numbers considerably.


--Larry Garfield

Raymond Muilwijk wrote:

Hello all,

I thought you might be interested in a new code coverage report to see 
the current status of drupal core. Have a look over here:

http://coverage.yarmu.nl

For those who don't know the code coverage report was created using the 
http://drupal.org/project/code_coverage project written by cwgordon. I 
just modified his version to work with current CVS and posted the patch 
on the project issue queue. The original coverage reports (from 2008) 
can be found on http://coverage.cwgordon.com/coverage/html.


Maybe we can make a effort to get this to run on drupal cvs every 2 
weeks / month on http://coverage.drupal.org? I'd like to help out to get 
it done!


Greetings,
Raymond

Re: [development] Creating recordset displays

[la...@garfieldtech.com]

There's also the "scaffolding" template module here, courtesy Jeff Eaton:

http://cvs.drupal.org/viewvc.py/drupal/contributions/docs/developer/examples/scaffolding_example/

Stupid long CVS URLs...

--Larry Garfield

andrew morton wrote:

I'd suggest looking at the Views Bulk Operation module:
http://drupal.org/project/views_bulk_operations

On Wed, Sep 23, 2009 at 8:12 AM, Raja Sekharan  wrote:

Hi all,

In many applications I create I find myself doing just one thing -
create CRUD interfaces in the admin panel. So far I have been writing
code to generate the list of items and everything.

Is it possible to create a recordset form using any API in drupal?
Here is what I want to do:

I want to generate a list for my entities [for example products]. It
should be very similar to the Gmail inbox - with a checkbox next to
each entry and the ability to sort according to any field. Users
should be able to check a set of items and select a drop down menu to
perform some action. This should be a form of course.

If this isn't possible with the Drupal API out of the box I'd be happy
if you can give me a brief outline of how this can be achieved.

Thanks in advance.

Raj Sekharan



--
“Computer science education cannot make anybody an expert programmer
any more than studying brushes and pigment can make somebody an expert
painter.”

Re: [development] Changing Input format for all instances of a field

[la...@garfieldtech.com]

The input format is stored as an integer in the database.  You should be 
able to just go to the appropriate CCK table in the database and run an 
UPDATE query on it manually.  You'll then want to clear all caches to 
make sure it takes effect.


I do not know of any more automated method, but it's a simple process in 
SQL.


--Larry Garfield

Brian Vuyk wrote:

Hello all!

I need to change the input format for all instances of a certain CCK 
field. What is the best way to go about this? There are about 2,000 
nodes that need to be updated. What's the best way to do this?


Thanks in advance!

Brian

Re: [development] Changing Input format for all instances of a field

[la...@garfieldtech.com]

Are you certain?  The field itself is not, or the format info is not?

It's probably best to move this to IRC, as it's turning into site 
support more than Drupal development. :-)


--Larry Garfield

Brian Vuyk wrote:
Which CCK table would that be? It's not stored in the content_type_* or 
content_field_* tables. It may be in the serialized arrays in 
content_node_field or content_node_field_instance, but changing those 
didn't seem to have an effect.


Brian

la...@garfieldtech.com wrote:
The input format is stored as an integer in the database.  You should 
be able to just go to the appropriate CCK table in the database and 
run an UPDATE query on it manually.  You'll then want to clear all 
caches to make sure it takes effect.


I do not know of any more automated method, but it's a simple process 
in SQL.


--Larry Garfield

Brian Vuyk wrote:

Hello all!

I need to change the input format for all instances of a certain CCK 
field. What is the best way to go about this? There are about 2,000 
nodes that need to be updated. What's the best way to do this?


Thanks in advance!

Brian

Re: [development] How to make Require_once refreshable

[la...@garfieldtech.com]

By default, PHP will reload files on disk every page request.  If it's 
not, then it's doing something weird.


Possible causes:

1) You're running APC in no-stat mode.  You need to restart apache for 
it to flush its cache.  This is not a good mode to run a dev server for 
the reason you're seeing.


2) You're running APC not in no-stat mode, but it's acting buggy and is 
not stating anyway.  Restart apache or disable APC.


3) You're actually editing the wrong file.  I have lots of copies of 
Drupal floating around my web directories.  It happens at times. :-)


4) The code you think is running is not actually running, so your debug 
statements are never reached.  This has happened to me, too.


5) Your OS or Apache are just being buggy.  Switch to a less buggy OS or 
Apache.


--Larry Garfield

Nancy Wichmann wrote:
I was trying to track down an issue I am having with the node module's 
content_types.inc so I stuck in some messages. Unfortunately, the menu 
system uses require_once to load these files, so my changes are not 
working. I really don't want to have to reboot every time I do 
something. Is there any quicker way to get PHP to reload these files?
 
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. 
King, Jr.
 

Re: [development] Distributed Pairprogramming for Drupal

[la...@garfieldtech.com]

Just one point to clarify, there is no "Drupal Team" that could decide 
en masse to use a tool like this.  Drupal is so distributed that we all 
have our own development workflows using a variety of tools, often in 
our basements rather than our offices (although there, too).  So "Could 
use and Drupal benefit" is really the wrong question to ask.


That said, I'm sure such a tool would prove useful to certain developers 
if they choose to use it.


Is it language-dependent?  Vis, most Eclipse devs work on Java, not PHP, 
so I am always wary of tools that may end up being centric to one 
particular language's development idiosyncrasies.


--Larry Garfield

Eike Starkmann wrote:

Dear Drupal Team,

My name is Eike Starkmann and I'm working working as part of the Saros 
Team at the Freie University in Berlin.


Saros is an Eclipse plugin for collaborative text editing and 
distributed pair programming, i.e. it allows two or more developers to 
work together in real-time on the same files. It is similar to Gobby, 
SubEthaEdit or Google Docs but focuses on programming in Eclipse.


It is my master thesis to figure out whether Saros is useful when 
developing Free/Open Source Software. I already was in contact with  to 
other projects, for example Typo3 and got some good response.


In my opinion Drupal can benefit from Saros because I think it brings 
many advantages to Open Source Software development:


* Distributed Pair Programming is like a live peer review. This should 
help with finding good design, get rid of bugs, increase readability, etc.


* Transferring knowledge should be easier to do when more than one 
person look at and work with the same code. This should also help to 
give new developers an introduction to the code.


* In contrast to screen sharing, Saros only shares your actions inside 
of Eclipse with regards to the project you are both working on (think 
privacy) and you are still independent to explore the project on your own.


Saros can be useful in the following contexts:

* Working on complicated problems in the code
* Performing code reviews
* Debugging
* Code presentation
* Code sprints
* Introducing new developers to the project
* ...

What do you think? Could you and Drupal benefit from doing pair 
programming using Saros?


If you are interested in Saros but still curious about how it works 
please visit our website or feel free to contact me.


I hope you will find Saros useful and give me feedback.

Kind regards, Eike Starkmann

Website: https://www.inf.fu-berlin.de/w/SE/DPP
Update Site: http://dpp.sf.net/update
Saros @ SF: http://sourceforge.net/projects/dpp/
Programming Languages Supported by Saros : 
https://www.inf.fu-berlin.de/w/SE/DPPCompatiblePlugin

Re: [development] Convention for naming contrib hooks?

[la...@garfieldtech.com]

There's no central canonical list, since hooks are fairly free-form. 
It's generally good practice to prefix a hook with the name of your 
module if you're not a core module (hook_yourmodulenamehere_hookname()), 
but that's not universal unfortunately.


--Larry Garfield

arthur wrote:

Hi-

Forgive me if this question is answered elsewhere- I've not found a 
comprehensive answer thus far.


With contrib modules sprawling ever more, it's extremely hard to keep 
track of what modules implement what kinds of hooks. For example, I got 
caught by file_field's hook_file_delete() when I implemented 
media_mover_api_file_delete() which had nothing to do with this hook. 
While I renamed my function, it's challenging at best to know the 
terrain. Is there a central place where contrib developers can list 
their hooks, or a naming convention that is agreed to that would help 
with this (eg: hook_HOOKNAME_HOOKMODULE() or something)?


thanks,

arthur

Re: [development] Distributed Pairprogramming for Drupal

[la...@garfieldtech.com]

Eike Starkmann wrote:

Vladimir Zlatanov wrote:

The tool is usable, in some limited fashion - project teams etc... It is
not a Drupal tool - there is no such beast - drupal is the tool itself.

Having said that the irc paste combo is used exactly in the manner you
suggest. Not just by the drupal crowd, but by most projects I've
touched.


That's a good point. So there is a need for collaborate editing or lets
say realtime collaborate working, which is often done using irc, but I
think that this way of collaboration can be improved.

Is there space for this tool - yes. Is it big? No. Until you can
collaborate with others - eclipse, emacs, textmate, put your favourite
environment, it is not going to be attractive. People don't like to be
dependent on a specific platform. Everyone has their own.


So you think nobody would change their favourite environment to eclipse
 just because working together with Saros? That might be true, but what
about doing reviews, you just have to use eclipse to do pair reviews,
you don't have to switch to eclipse totally, you can keep on developing
with what ever you want.

Greets, Eike


I've bounced between a number of different IDEs and dislike most of 
them.  At the moment I'm using Eclipse.  Really, it is NOT a casual-use 
tool.  Especially for Drupal, it's not worth it unless you adopt it and 
take the time to customize it.  I can't see anyone using Eclipse just 
for Saros and "other" for everything else.


If adopted by a couple of people it could be enough to get someone to 
switch to Eclipse, perhaps, especially if some other Eclipse tools like 
Mylin had good Drupal-specific integration, but I can't see Eclipse 
itself as a casual-use IDE.


(I say this having not tried it yet myself.)

--Larry Garfield

[development] PHP Standards Group

[la...@garfieldtech.com]

Back in the spring, a group of PHP developers from several popular "pure 
frameworks" got together and started a PHP standards working group. 
Their goal was to standardize certain OO coding standards, in particular 
the use of namespaces, across PHP projects, even if such standards 
necessitated some changes in the participating projects' existing code 
bases.


There was some fallout about the group being self-declared and trying to 
establish project standards by fiat, with a number of people, myself 
included, objecting to either the fait accomplis presentation, the 
details of the proposed standards, or both.  Eventually the core team 
moved off to an invite-only list, and I largely lost track of them.


Yesterday, they decided they should invite in representatives from a few 
other frameworks and projects, including Drupal.  I discovered this when 
I suddenly found myself on the list and getting messages, as I'd been 
sitting in the pending membership queue for months. :-)  So apparently 
I'm now the "Drupal representative".  Goodie...


So before I open my big mouth, to what degree are we interested in being 
involved, and to what degree are we willing to play by the standards 
this group develops?


Personally, I think we should try to do so where possible.  It's good 
for inter-operability, reduces the learning curve for PHP-knowledgeable 
developers coming into Drupal, and frankly a lot of these people have 
been working with OO PHP a lot longer than we have so there's much to be 
learned from them.  It also means that we can begin to shift ourselves 
in the "right" direction for whenever we're able to drop PHP 5.2 and 
rely on PHP 5.3 namespaces, which will open up all sorts of new and 
exciting power and weirdness.


However, I'm not sure that we should commit to following the developed 
standards, period.  As of the last draft I saw, some of them would not, 
I think, even be compatible with a modular full-stack framework like 
Drupal to begin with, mostly regarding a universally-applicable autoload 
pattern.


So I would like to go into the process with a statement of "we'll be 
involved in developing such standards and will adopt them wherever 
feasible, but we do not commit to following all standards if they are 
incompatible with Drupal's basic architecture."


+1, -1, feedback, flames, recriminations, encouragements, death threats...?

--Larry Garfield

Re: [development] PHP Standards Group

[la...@garfieldtech.com]

The current draft is here, I think: 
http://groups.google.com/group/php-standards/web/final-proposal


It seems to cover fewer things than they used to, but the one it does 
cover is the one that is least Drupal-friendly; specifically it mandates 
a direct Java-style mapping from namespace and class name to file name. 
 I dislike that and find it fundamentally Drupal-incompatible, but 
we'll see.


As for the level of workload, that depends on what the standards end up 
as and how much of them we decide to adopt.  Some of the earlier bits (I 
don't know what's happened to them in the past few months), like always 
naming an interface *Interface, are already part of our coding standards 
because I started doing that for DBTNG, which became most of our OO 
standards.  (That was coincidental at first, and later on deliberate.) 
There's already some exception-related changes we'll need to make to 
conform to our own standards, but those should be low-impact.


The big impact, I think, will be related to namespaces.  We're not using 
those yet, and can't until we require PHP 5.3.  The odds of us doing 
that for Drupal 8 are, I think, slim.  Hopefully by Drupal 9 we can do 
so, but that will depend on how the PHP market evolves.  (I wonder if I 
need to start a GoPHP 5.3 project... )  TBD.  If we know what the 
standard is going to be, though, we can certainly look at moving 
ourselves in a direction that will be easy to migrate to namespaces when 
we get there.  I've been giving that a fair bit of thought recently 
(mostly relating to treating modules as a namespace, or sub-namespace), 
but there's no game plan there yet.  If we can use the work of this 
group as a long-term roadmap planning tool, that would be great.


Ken Winters: Yep, I'm all over that thread. ;-)  ("Crell" is me.)

Brian Vuyk wrote:

Larry,

Your approach on the matter sounds reasonable.

In the abstract, as far as it meshes with the current architecture, we 
should try to comply in the interests of accessibility and 
interoperability of our codebase.


That said, I have no idea what their standards actually entail. what 
would we be looking at in terms of code modifications to match up with 
these new standards? What kind of refactoring and rewriting would this 
take? Would this be a relatively simple job, or would we be looking at a 
good portion of the D8 or D9 development cycle to come to compatibility? 
What kind of workload will this place on the Drupal dev community?


Either way, you are a good person to have in that discussion.

Brian Vuyk
http://www.brianvuyk.com


la...@garfieldtech.com wrote:
Back in the spring, a group of PHP developers from several popular 
"pure frameworks" got together and started a PHP standards working 
group. Their goal was to standardize certain OO coding standards, in 
particular the use of namespaces, across PHP projects, even if such 
standards necessitated some changes in the participating projects' 
existing code bases.


There was some fallout about the group being self-declared and trying 
to establish project standards by fiat, with a number of people, 
myself included, objecting to either the fait accomplis presentation, 
the details of the proposed standards, or both.  Eventually the core 
team moved off to an invite-only list, and I largely lost track of them.


Yesterday, they decided they should invite in representatives from a 
few other frameworks and projects, including Drupal.  I discovered 
this when I suddenly found myself on the list and getting messages, as 
I'd been sitting in the pending membership queue for months. :-)  So 
apparently I'm now the "Drupal representative".  Goodie...


So before I open my big mouth, to what degree are we interested in 
being involved, and to what degree are we willing to play by the 
standards this group develops?


Personally, I think we should try to do so where possible.  It's good 
for inter-operability, reduces the learning curve for 
PHP-knowledgeable developers coming into Drupal, and frankly a lot of 
these people have been working with OO PHP a lot longer than we have 
so there's much to be learned from them.  It also means that we can 
begin to shift ourselves in the "right" direction for whenever we're 
able to drop PHP 5.2 and rely on PHP 5.3 namespaces, which will open 
up all sorts of new and exciting power and weirdness.


However, I'm not sure that we should commit to following the developed 
standards, period.  As of the last draft I saw, some of them would 
not, I think, even be compatible with a modular full-stack framework 
like Drupal to begin with, mostly regarding a universally-applicable 
autoload pattern.


So I would like to go into the process with a statement of "we'll be 
involved in developing such standards and will adopt them wherever 
feasible, but we do not commit to following all s

Re: [development] Move Dev List to groups.drupal.org

[la...@garfieldtech.com]

Put me in the same column.  I loathe forums with a passion.  They are a 
horrifically bad interface for pretty much everything other than 
"getting indexed by Google".  Ironically, the Drupal project* issue 
queues are the forum-type system I despite the least, out of all the 
ones I've used.  Despite email architecture itself being a patchwork of 
crap (SMTP, POP, IMAP, all with ugly configs and that's before you even 
get to spam or filtering or MIME), it's still a much better interface 
for most conversations, even those with poor signal to noise ratio, than 
any forum software I've seen, Drupal or otherwise.


There's a reason I've never been active in the Drupal forums, only lists 
and IRC.


--Larry Garfield

Nancy Wichmann wrote:
If this list moves to g.d.o, I will no longer participate. I find g.d.o. 
difficult to locate much of anything. Here on this list, I can read the 
first few of a thread and decide if I have any interest in following it 
any further. If I do, I keep reading; if I do not, I delete it 
automatically. As for searching, I can do that in the emails I retain.


 


Nancy E. Wichmann, PMP

Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. 
King, Jr.

Re: [development] new dev q: are mysql queries possible within drupal?

[la...@garfieldtech.com]

spartaguy spartaguy wrote:


Thanks to everyone that replied.


To summarise then:

 1)  I need to make a custom module.
 2) The module should have a block for displaying the query and a menu hook
 3) I can add the module to either primary links or navigation as a menu 
item

 4) Rendered HTML using mysql commands is quite straight forward
 5) The tables being queried are easier to access within the main drupal 
d/b but i can use a different db
 


Regarding a different db, does this command:

db_set_active('customerdb');

make *all* db queries go through customerdb or just the ones for my module?
ie will drupal have any issues accessing the data it needs from say 
"drupaldb" if I dont change

the active db back again?


db_set_active('customdb'); will make *all* queries run against customdb, 
until you call db_set_active(); to set it back to the default DB.  For 
that reason, you should minimize the amount of work you do while using 
that DB.  For instance:


function dostuff() {

  $old_db = db_set_active('custom');

  $data = db_fetch_object(db_query("SELECT ..."));

  db_set_active($old_db);

  // Do some manipulation of $data here.

  return theme('mytheme_key', $data, $something_else);
}

Note that in the above, you put all of your DB interaction together in 
one place, switch the DB just long enough to run that, and then go back 
to normal.  That ensures that once you get into theme calls or calling 
other Drupal functions you're back on the main Drupal database so that 
other code doesn't get confused.


--Larry Garfield

Re: [development] CVS Approval Policy: was Re: new features in D6 core?

[la...@garfieldtech.com]

Ashraf Amayreh wrote:

If each module developer HAD TO post to the list before being able to 
create his project the result could have been much better. Currently 
there's no holding any CVS owner from creating as many new modules 
without even doing basic research and no one can know it happened or 
object to it. I'm VERY sure this would be different if they HAD TO post 
to the dev list first before being able to create their projects. Again, 
I suggested very reasonable and easily implementable suggestions that no 
one has really addressed directly yet. If my idea is a problem then I 
would like to someone to point the drawbacks. Seeing that this will only 
affect people who already have a CVS account then please don't use the 
"barrier" argument as a response.


Regards,
Ashraf Amayreh


If adding modules to Drupal.org becomes too difficult, people will not 
bother and will just host them elsewhere, in a dozen different 
elsewhere's.  That's the worst possible scenario, and if anything would 
make duplication worse because there wouldn't even be a single 
collection to check for existing modules.


--Larry Garfield

Re: [development] GPL 2 violation by integrationservic.es

[la...@garfieldtech.com]

*sigh*

There is nothing in the GPL that says you cannot sell a module.  The 
module author is free to charge $1 million dollars a copy if he wants 
to... provided that the code is then licensed to buyers under the GPL, 
which means the buyer could redistribute it for free if they felt like 
it.  So just charging for a module does not constitute a GPL violation. 
 We've been over this, and the dev list is not the place to be 
rehashing it.


I've already replied to that effect to the mentioned thread.

--Larry Garfield
Director of Legal Affairs
Drupal Association

Brian Vuyk wrote:
There are several long-running discussions on g.d.o over whether or not 
a module constitutes a derivative of Drupal. Unfortunately, there isn't 
much in the way of legal precedent to give definition to the term 
'derivative' in the context of the GPL.


While it is the Drupal Association's interpretation that a module *is* 
derivative code, this is a somewhat legal grey area.


If a module is considered to not be a derivative, then it doesn't 
automatically gain the GPL, and there is nothing wrong with selling it, 
and prosecuting anyone who redistributes it.


If it is indeed a derivative (the stance I take), then modules 
automatically assume the full protection / freedom of the GPL. In which 
case this developer is violating the GPL.


In short, someone should purchase the module, and exercise their GPL 
freedom to post it to D.org, or take over maintainership of the module.


Brian

Naheem Zaffar wrote:



2009/11/19 Alex Barth >



This may have come up before, but
http://integrationservic.es/drupal.php launched on Nov 12 and
appears to be violating drupal's GPL2 by charging 33 $ for a
module download.


The GPL does not say that the module has to be for free. However once 
the module has been "distributed" to other individuals, no additional 
restrictions above the GPL can be added, so if the person has  clause 
that the purchasers cannot sell/pass the module onto others, that 
would be a problem, otherwise, no it wouldn't.


IANAL, but that is my understanding.

Re: [development] GPL 2 violation by integrationservic.es

[la...@garfieldtech.com]

Please follow up in the mentioned thread then, not here.

--Larry Garfield

Brian Vuyk wrote:
Nowhere did I claim selling a module was wrong. Of course they can sell 
a GPL module.


The problem here is the code is not being released under the GPL.

Brian

la...@garfieldtech.com wrote:

*sigh*

There is nothing in the GPL that says you cannot sell a module.  The 
module author is free to charge $1 million dollars a copy if he wants 
to... provided that the code is then licensed to buyers under the GPL, 
which means the buyer could redistribute it for free if they felt like 
it.  So just charging for a module does not constitute a GPL 
violation.  We've been over this, and the dev list is not the place to 
be rehashing it.


I've already replied to that effect to the mentioned thread.

--Larry Garfield
Director of Legal Affairs
Drupal Association

Brian Vuyk wrote:
There are several long-running discussions on g.d.o over whether or 
not a module constitutes a derivative of Drupal. Unfortunately, there 
isn't much in the way of legal precedent to give definition to the 
term 'derivative' in the context of the GPL.


While it is the Drupal Association's interpretation that a module 
*is* derivative code, this is a somewhat legal grey area.


If a module is considered to not be a derivative, then it doesn't 
automatically gain the GPL, and there is nothing wrong with selling 
it, and prosecuting anyone who redistributes it.


If it is indeed a derivative (the stance I take), then modules 
automatically assume the full protection / freedom of the GPL. In 
which case this developer is violating the GPL.


In short, someone should purchase the module, and exercise their GPL 
freedom to post it to D.org, or take over maintainership of the module.


Brian

Naheem Zaffar wrote:



2009/11/19 Alex Barth <mailto:a...@developmentseed.org>>



This may have come up before, but
http://integrationservic.es/drupal.php launched on Nov 12 and
appears to be violating drupal's GPL2 by charging 33 $ for a
module download.


The GPL does not say that the module has to be for free. However 
once the module has been "distributed" to other individuals, no 
additional restrictions above the GPL can be added, so if the person 
has  clause that the purchasers cannot sell/pass the module onto 
others, that would be a problem, otherwise, no it wouldn't.


IANAL, but that is my understanding.

Re: [development] Creative querying

[la...@garfieldtech.com]

Also be aware that, at least on MySQL, subqueries in a WHERE clause get 
executed for every otherwise-matching record.  Depending on your dataset 
that could eat up a lot of time.  Subqueries in a SELECT or FROM clause 
are only executed once, so those are fine.


With a proper join against a weighting table, though, the subquery 
shouldn't even be necessary.


--Larry Garfield

Ken Winters wrote:
select * from users where uid in (select uid from users_roles where rid 
in (4,5,6,7,8));


Note that I dropped the rid column from the results, but your query 
didn't provide all that useful results for it to start with (picked 
one).  If you actually need it then you may still need a join, and also 
might need something like group_concat.


- Ken Winters

On Nov 23, 2009, at 10:41 AM, Brian Vuyk wrote:

1.) We are including extra data from the users table (wasn't central 
to the question, so I omitted it to simplify)

2.) How would you structure this exactly with subquery?

Brian

Ken Winters wrote:

On Nov 23, 2009, at 10:18 AM, Brian Vuyk wrote:


SELECT DISTINCT u.uid, ur.rid FROM {users} u RIGHT JOIN 
{users_roles} ur ON ur.uid = u.uid WHERE rid = 6 OR rid = 8 OR rid = 
5 OR rid = 7 OR rid = 4 GROUP BY uid;


Brian


1) Why are you doing a join when all the info you are selecting is in 
the users_roles table?  If you don't need it for some other reason, 
problem solved.
2) I've found it's generally better to use subqueries (where X in 
(select Y from Z)) rather than join and group.


- Ken Winters

Re: [development] Getting SVN to deal with orphaned and new files

[la...@garfieldtech.com]

SVN isn't quite as bad for this as you make it out to be. :-)  You can do:

svn add --force sites/all/modules

and it will recursively add any files under that directory that it 
doesn't already know about.  Be careful of ._ files and similar crap 
that OS X may create. :-)


That's actually my usual workflow at this point.  Drush dl to grab new 
modules, drush update to update a module, followed by the svn command 
above and then commit.  It doesn't handle file deletes or major file 
reorganization, but those are quite rare.


And I almost never check out a module straight from CVS.  If I want a 
dev version, you can tell Drush to get that for you.


--Larry Garfield

Shai Gluskin wrote:
I get modules from d.o. from CVS, then I commit them to my own 
repository with SVN.


When updating modules I've doing SVN del, CVS co, SVN add instead of 
simply CVS up because of orphaned and new files. SVN freaks out over 
orphans and the new files are just a pain since you need to SVN add for 
each one.


But I just installed Drush and I'm so excited about making all this 
easy. So I'm motivated to finally ask for help around this.


So if you commit CVS versions of contrib to SVN, what is your method for 
dealing with orphans and new files?


Thanks,

Shai

Re: [development] is drupal a MVC stuff

[la...@garfieldtech.com]

Andrew Berry wrote:

On 2009-12-11, at 9:33 AM, Damien Tournoud wrote:


a big part of the view and the controller is
actually handled by the browser.


This is true for how %99.9 percent of the Drupal installations out there, but a 
"view" doesn't have to be graphical. A View could be RSS, XML, Postscript, etc. 
IMO the $page array in D7 brings Drupal much closer to an MVC-like design, as you now 
have an abstracted representation of data before it's processed by the View (whatever 
your theme_* and .tpl.php files do).

--Andrew


The defining attribute of MVC is, IMO, that the View component has 
direct access to the Model component using an observer relationship, 
without going through a separate Controller.


hook_page_alter() is in no way a direct observer relationship between 
the View component and the Model component.  *_alter hooks are a 
pipes-and-filter approach, or, arguably, visitor pattern.


Drupal is very much not an MVC design.  It's not true PAC either, but I 
have and do argue that it is closer to PAC than MVC.


Someone needs to correct the Wikipedia page, which is simply wrong in 
this regard.


--Larry Garfield

Re: [development] Drupal's target audience

[la...@garfieldtech.com]

Brian Vuyk wrote:
I think this whole overlay-in-core issue has kind of raised a fairly 
significant issue to my mind - who exactly is Drupal's target audience?


Everyone!  Anyone!  The whole world!

Which is of course a problem.  "You can please some of the people all of 
the time, and all of the people some of the time, but you can't please 
all of the people all of the time."


We do very much need to change that attitude, or at least acknowledge 
that there are *layers* of target audience that need to be addressed 
separately in order to be addressed properly.  Insert smallcore debate 
here so we don't have to rehash it. :-)


*snip*

I wonder if there is call to have a separate, supported install profile 
for more advanced users that does away with some of these things?


Thoughts?


That's what the "expert" profile in core is for.  Everything is disabled 
by default.


'course, I don't recall the last time I used a non-custom install 
profile.  All Palantir sites are built from a custom profile, although 
with drush and now features that profile is thinner than it used to be.


--Larry Garfield

Re: [development] Good practice for module development

[la...@garfieldtech.com]

First and foremost, leverage the menu system's lazy-loading capabilities:

http://drupal.org/node/146172

That won't work for everything, but it will work for page callbacks. 
The theme system has a parallel design.


--Larry Garfield

ktt wrote:

Hello,

Is there any good practice advises for developing modules?
*.module file gets too long. I would like to put form definitions
to one file, block definitions to another.

Regards,
Ktt

Re: [development] Distributing "bi-modal" Drupal modules

[la...@garfieldtech.com]

I certainly hope they don't do it a lot.  As of Drupal 6, info files 
must specify their core version and will be rejected by any other core 
version.


If you have code that doesn't change between two versions, sure, you can 
put it into an include file of your own.  And then look into a good 
source code management system.  (Where good = not CVS.  It looks like 
Drupal.org has finally started the process of moving toward git, which 
should make such code management substantially easier.)


Really, this is exactly where good branch and merge management is your 
friend.  There's no reason at all to ship "dud" D6 code with a D7 module 
or "dud" D7 code with a D6 module.


--Larry Garfield

Aaron Winborn wrote:
If folks start doing a lot of that, might be nice to add support for an 
'ignore-if-not-supported' property or something to the .info file so it 
doesn't show up w/ a warning in the other version.


Brian Vuyk wrote:
That is, you could probably release a folder structure / package along 
the lines of:


mymodule/
 includes/shared.inc
 mymodule_d6.module
 mymodule_d6.info
 mymodule_d7.module
 mymodule_d7.info

Where 'includes/shared.inc' would include logic shared between the two 
different modules. Both modules would show up on the 'Modules' page, 
but only the one corresponding to the correct version of Drupal could 
be enabled.

Re: [development] No suitable nodes available at RackspaceCloud (Mosso)

[la...@garfieldtech.com]

Drupal by design doesn't generate output of any kind until the last 
second, and then sends the entire page as one giant string.  That is 
what allows us to do all sorts of fun things in the theme layer or HTTP 
redirection before content gets sent.


That said, if I understood the original message Rackspace is saying the 
proxy server is timing out after 30 *seconds* of no response?  Even the 
heaviest Drupal page shouldn't get anywhere near that time.  3-4 seconds 
for something other than selected admin pages is considered an eternity, 
at least for the PHP time.  There's something else going on here besides 
Drupal not being the fastest PHP app out there...


--Larry Garfield

Tomáš Fülöpp (vacilando.org) wrote:
(Interesting, Brian; I also were promised shell pretty soon about a year 
ago. It's a shame - MediaTemple has shell /and /also a breakdown of 
compute cycles per script...)


Anyway -- Victor's note about shortening PHP timeout brought me to 
thinking about measuring the time since the start of the execution and 
issuing flush() each time the process might time out.


Two questions:

   1. what is the most suitable Drupal function for this -- it needs to
  be something that runs regularly and for all kind of pages
   2. for Drupal, is it enough to issue flush() or is ob_end_flush()
  also needed, or something else

Thanks a million for any ideas;

Tomáš / Vacilando



On Thu, Feb 18, 2010 at 15:46, Brian Vuyk > wrote:


I've run into this with a few of my client sites, but they haven't
even been high-traffic sites.

Personally, I just don't think the RS Cloud is a good match for
Drupal. Combine that with the recent security issues they've had,
occasional inexplicable downtime, the 'no suitable nodes' and the
lack of a shell, and I am moving my sites away as quick as I can.

The shell issue is really sensitive for me - about 14 months ago, my
previous host ran into... issues... and could no longer offer
hosting. So, I was in a pinch and Rackspace (then Mosso) looked very
good apart from the lack of a shell. I talked to their customer
service reps, and was informed that shell access for the cloud was
in pre-release testing, and was scheduled to go live the next week.

In a burst of poor judgement, I decided that the package they
offered was good enough to do without shell access for a week, so I
bought in, and transferred my sites. 14 months later, shell access
still hasn't been released, and I've had to move all my more
critical  / development-intensive sites off of their service in the
meantime.

Brian




Tomáš Fülöpp (vacilando.org ) wrote:

Hi,

At RackspaceCloud (former Mosso) I've been plagued with a very
unfortunate problem that i crippling both my work and the work of
my clients -- namely the infamous error message "Unfortunately
there were no suitable nodes available to serve this request."
Those of you at RS Cloud must have bumped into it. It is cryptic
and happens unpredictably. The cloud is very stable and scalable,
but for any a little bit heavier Drupal installation people do
start getting these errors.

*Basically, it is a generic error thrown by load balanced systems
that occurs as a result of a script exceeding a maximum timeout
value (not the PHP timeout value!) If a client connection does not
receive a response from the server after approximately 30 to 60
seconds the load balancer will close the connection and the client
will immediately receive the error message. In most cases, the
script will continue to execute until it reaches completion,
throws an error, or times out on the server, but the client will
not see the page load as expected and will instead receive this
error.*

I've used Boost for anonymous pages, Parallel, Memcache, etc., all
of which helped and anonymous users /usually/ don't get this
error. The problem is with admin or any other a bit heavier work
of logged in users. Even for basic Drupal websites with not too
many modules! Pages like the list of modules, or the status page,
i.e. heavy database or file requests, or API calls in PHP, are
very likely to time out.

Over the past year I've had a number of discussions with techs and
admins at that cloud, but the situation is unresolved. They
recognize the problem but maintain this is due to the
special/unusual setup they use for their cloud. It is not a
problem for some other CMS / frameworks. E.g. a very heavy
MediaWiki installation runs just fine. Drupal seems to be less
compatible with their system, somehow, somewhere.

*Now, why do I mention all this in the development list? I've been
intrigued by one little ray of hope in their words: "if a client
connection does not receive a response from the server after
approximately 30 to

Re: [development] Force admin login

[la...@garfieldtech.com]

You can always edit the database directly.

It sounds like a cookie problem, though.  Try setting the cookie domain 
explicitly in your settings.php file to just example.com (not 
www.example.com, or whatever).


Also, check to make sure that uid 0 is still intact in the database. 
That's another common source of weirdness, in my experience.


--Larry Garfield

Tomáš Fülöpp (vacilando.org) wrote:

Hi,

Is there a backdoor way to force admin login if everything fails? 
Something like the way $update_free_access is changed to TRUE to allow 
running update.php?


A client got locked out of D6.15 completely, including admin. Login 
seems to work (I see admin only links on logon), cookies are set, but 
only on the initial page any subsequent click is treated as done by 
an anonymous user (checked the watchdog this way). I've cleared all 
browser caches, Drupal caches via the db, also the Drupal sessions 
table, checked the cookie domain, the admin user record exists in the 
user table, etc. in settings.php, deleted and re-uploaded D6.15. Nothing 
in the php logs. Nothing unusual in watchdog - just access denied by 
anonymous... Spent an equivalent of a day on this but I know there is a 
ton of things I can still try - e.g. rebuild access rights. But I do 
need to log in first, only by myself. So... is there a way to force 
admin login? Cannot find this info anywhere.


Thanks!

Tomáš

Re: [development] order in which regions are rendered

[la...@garfieldtech.com]

That actually seems like a rather screwy thing to be doing in the first 
place. :-)  Perhaps you can explain what you're trying to accomplish and 
we could figure out a better approach?  IME, if you care about the order 
that blocks are rendered in, or in which region they appear, more often 
than not you have a design flaw somewhere in your logic.


--Larry Garfield

On 3/22/10 9:32 AM, Ashraf Amayreh wrote:

Thanks for the replies. You're right, the regions do render as declared
inside the .info file, but knowing that still doesn't solve the issue.

For example, some regions are added through preprocess
(theme_preprocess_node) which are rendered on node pages before the rest
of the regions. Anything inside the node.tpl.php is also rendered before
all other regions. So you still can't guarantee that one region is
rendered before another. What I need is to generate javascript inside
blocks according to their placement on the page. What I tried was
placing a static variable inside hook_block on $op = view and
incrementing that, but as I showed, this didn't solve the problem
because you can't be sure what regions will be rendered in what order.

The only way I see it is to somehow modify the fully rendered page HTML
before it's sent to the browser using regular expressions. Is there a
way to do that? And if doable, how costly in performance would it be?

--
Best Regards,
Ashraf Amayreh
CEO | O-Minds
Cell. 962 78 807
Tel. 962 6 5655150
Fax. 962 6 5675150

o-minds.com 
web development | web design
user experience | branding design

Re: [development] Interacting with Views Tabs via code

[la...@garfieldtech.com]

Views does all of its menu manipulation in hook_menu_alter already, so 
if your hook_menu_alter runs first then the views additions won't be 
there.  Try setting your module weight to heavier than views.


Alternatively, create your page first using hook_menu as the default tab 
and then tweak the view to just add tabs to the page you already 
created.  That may be the cleaner approach.


--Larry Garfield

On 3/29/10 10:58 AM, Sam Tresler wrote:

Hello,

Not sure if this is the best place, but I've come across an interesting
problem and I'm not certain how to proceed. I have a 3 tabbed view (you
can actually see the live version here:
http://livestrongaction.org/featured_dedications). I want to add a 4th
tab, and thought this would be simply adding a custom module with
hook_menu and a MENU_LOCAL_TASK. However, it appears that views is doing
something that prevents hook_menu from interacting there. I next thought
I would try hook_menu_alter, but I can't see the three tabs being
rendered in the &$items array passed into that hook.

Now, I could just intercept this at the theme level and add what I
needed, but that seems kludgy. I'm tempted to move the entire view into
code, but not sure how that would necessarily help this situtation. I
may ask on IRC< or the views support queue, but thought this list may be
able to give me a few leads.

Any idea how to get a menu tab to render on a tabbed view? Hope I'm not
missing something obvious. Thanks in advance.

-Sam Tresler

Re: [development] php4

[la...@garfieldtech.com]

Official position: Drupal 6 core runs on PHP 4.  Contribs are at their 
discretion to decide what they support.  Drupal 7 and its contribs will 
require PHP 5.2 or higher.


My personal position: The host in question will likely be deservedly out 
of business soon.  Seriously, PHP 5 is not hard to support.  It's been 3 
years since the developer community officially abandoned PHP 4 and 2 
since the PHP internals team did so.  PHP 4 is getting no security 
updates whatsoever, and there are known, documented security holes in it 
that will not be addressed.


If your client is too cheap to get a host that pays attention to the 
past 6 years and at least pretends to care about security, then frankly 
I'd question if they're too cheap to pay you for the work.  It's not 
like cheap PHP 5 hosts are hard to find.


--Larry Garfield

On 6/14/10 1:09 PM, Domenic Santangelo wrote:

Hypothetically, if a client wanted you to build a Drupal site (complexity of 
say, 2, where 10 is economist.com) and they insisted on a specific host -- and 
this host only supports php4, what would you tell them? So far I've got,

-Core will work but many contribs will not (filefield, date, ubercart, etc)
-Prepare for added development time that you wouldn't have to otherwise pay for
-???

What would you say, hypothetically? Any official stance on php4 from d.o?

Thanks,
-D

Re: [development] State of geo and google map modules?

[la...@garfieldtech.com]

On 6/22/10 11:30 AM, Domenic Santangelo wrote:


On Jun 22, 2010, at 12:53 AM, Ronald Ashri wrote:


In the meantime, I would suggest a careful look at the Openlayers
(http://drupal.org/project/openlayers) module if I were you. It is
powerful and once you get into it gives you a lot of flexibility.


OpenLayers does indeed look cool. It looks like a bit of overkilll
perhaps... what I'm trying to do seems straightforward enough:

1) nodes of type "event" have an "address" field. Fill in the address.
2) Single node pages have a map with a pin on it
3) views of multiple events have a single map with many pins <- (this is
where gmap + geo is croaking)
4) ability to filter that view by distance -- xx miles from ZIP code.
5) all US addresses

The modules I'm seeing do everything + the kitchen sink, minus one thing
I need to do. Or they have dependencies that are broken. Am I
inappropriately lost here? Am I just being dense?

-D


We've had good experiences with the Mapstraction module, which uses 
Views for that purpose.


http://drupal.org/project/mapstraction

--Larry Garfield

Re: [development] [OT] Eclipse Helios

[la...@garfieldtech.com]

I actually had to downgrade from Helios back to Ganymede on my OS X 
system.  I gave it plenty of RAM, but I still kept getting stack 
overflow errors when opening common.inc, theme.inc, and other large 
files.  The code completion is actually useful in Helios, which is more 
than I can say for Ganymede, but the repeated bombing on large files 
combined with randomly breaking my debugger on certain projects forced 
me to go back to the previous version.


I've heard that these are known, reported issues so I may try it again 
in a few months.


Caveat emptor and all that.

--Larry Garfield

On 6/29/10 5:16 AM, Pierre Rineau wrote:

Hi all,

I just tested Eclipse Helios, latest release from this month (using a
Linux 64bits OS), and I felt a real change, PDT PHP editor seems to be
really faster (and seems to do a better code completion also!).

Others noticeable changes is, I did not tested yet, it seems they have
reworked the JavaScript support.

For Eclipse users, you should give this new release a trial, for others,
if you ever have been looking for a good IDE, you might want to test it
(I'm not forcing you guys, and don't want to throw a flameware).

Regards,
Pierre.

Re: [development] Module suggestion

[la...@garfieldtech.com]

On 7/12/10 4:46 AM, icerain wrote:

Thanks for reply.

All these module seems in initial stage.
Module question: is for the usage of asking questions to administrator,
but i want all users can answer the questions.
Module question_answer: have evident bugs, after fixed myself, can one
of the comment as answer only once. Can not change the selection after then.
Module custom_review: only one review can be submitted.
Module nodereview: For D6, only has development snapshot.


Nodereview is looking for a new maintainer as I don't have time to do 
anything with it.  If you want to help out I can give you CVS access. 
(Really, I've been trying to get rid of that module for years.)


--Larry Garfield

Re: [development] (no subject)

[la...@garfieldtech.com]

I generally warn people away from modifying another module's tables 
(core being a collection of modules).  The potential for collision, 
confusion, and stuff randomly disappearing on you is too great.


If you have a one-off where you know what your situation is, then you 
can sometimes get away with it.  A contrib module on d.o that starts 
messing with the user table, for instance, is a code smell that I want 
to stay far away from it.


JOINs, especially on indexed integer fields (like nid, uid, etc.) are 
really really fast.  SQL is designed to make them fast.  Don't fear the 
join.


--Larry Garfield

On 7/12/10 2:53 PM, Brian Fending wrote:

+1 for moshe's .02. Contrib should not, IMO, try to modify that
extensively. Reference point is CCK, which gained simplicity in its
inclusion in Core, but did not assume it. Kosher Law notwithstanding.


On Mon, Jul 12, 2010 at 3:04 PM, Moshe Weitzman mailto:weitz...@tejasa.com>> wrote:

my .02 is that such altering is quite reasonable for custom
programming but not so kosher for contrib modules

On Mon, Jul 12, 2010 at 12:19 PM, nan wich mailto:nan_w...@bellsouth.net>> wrote:
 > Is there an official stance on using hook_schema_alter to
add columns to
 > core tables? For example, we collect additional data on anonymous
comments
 > and want to actually save that data. Rather than creating another
table (and
 > subsequent JOINs), I'd just as soon stuff that data into
the comments table,
 > where it belongs. Should we ever disable comments (unlikely), we
probably
 > wouldn't mind losing that data too.
 >
 >
 > Nancy E. Wichmann, PMP
 >
 > Injustice anywhere is a threat to justice everywhere. -- Dr.
Martin L. King,
 > Jr.

Re: [development] Batch API on cron

[la...@garfieldtech.com]

I've used drupal_queue on a project recently and I very much like it. 
It's a backport of the Drupal 7 queue system, too, which gives you an 
easier upgrade path in the future.  It was designed to scale to millions 
of queue items, although not withe the default backend plugin.  The 
default one is good for a couple hundred records, probably.


It's a really nice architecture overall.

--Larry Garfield

On 7/15/10 6:36 AM, Yves Chedemois wrote:

Queue D6 backport sounds a good idea -
http://drupal.org/project/drupal_queue
Never tested it, though.

Yves

Le 15/07/2010 13:28, Sven Decabooter a écrit :

That's clear, and it makes sense. Thanks Yves!

Any pointers as to how I could have large chunks of data processed on
cron in another way?


Sven



On Thu, Jul 15, 2010 at 1:25 PM, Yves Chedemois mailto:yched.dru...@free.fr>> wrote:

Batch API works around the PHP timeout limitation by relying on a
client browser to iterate separate requests, each of which stays
below the time limitation.
So yes, Batch API can only be used in a UI context, which excludes
cron.

For the same reason, it is not recommended to fire a batch
processing inside an API function, since you cannot ensure it will
be executed in a safe-for-batch context.

Yched

Le 15/07/2010 11:01, Sven Decabooter a écrit :

Hi,

I'm reading contradicting posts about running Batch API
processes on cron. This is for Drupal 6 BTW.
I have tried implementing a batch functionality that should be
run on cron, but it doesn't seem to process the work that
needs to be done.
I assume this is because running the cron through a
commandline command doesn't allow for javascript...

So my questions:
- Have I implemented Batch API incorrectly, and should it
normally work also on cron?
- What is the best way to run a process that would normally
trigger a php script timeout? Can I use the Queue module for that?

I'm sure plenty of people have already tried doing this, so
I'm not sure why I can find little consistent information
about it.

Thanks for your feedback.

Sven

Re: [development] MySql Performance Problem

[la...@garfieldtech.com]

The query is doing a WHERE on the node table and an ORDER BY on the 
radioactivity table.  That will force a temp table no matter what you 
do.  If the temp table is larger than some size (no idea how MySQL 
determines that size) it will dump it to disk, hence the filesort.


Your best bet is to try and reduce the size of the result set as much as 
possible to keep the temp table small.  That is, if you can throw 
anything else into the WHERE clause on the node table (eg, node type, 
created recently, etc.) that will probably help.


Indexing the votingapi fields you're joining on may help.  Don't worry 
about the write cost.  Updating an index on an integer field is pretty 
fast, and if you're then joining on that field it's going to be a net 
win in most cases.  Try it and see how much difference it makes.


--Larry Garfield

On 7/19/10 1:11 PM, nan wich wrote:

Print_page_counter and print_mail_page_counter both have indexes on
"path" which is how I am accessing them.
I added "AND v.content_type='node'" to the votingapi_cache because it
has an index on content_type and content_id. That cut the time in half.
Radioactivity has an index on id, class, and decay_profile (in that
order). My query has id and class; but does not have decay_profile.
Thank you, it is faster now, but I'd still like it even faster.
So I now have
SELECT n.nid, n.title, n.status, n.created, n.uid, ra.energy,
nc.totalcount, nc.daycount,
ppc.totalcount AS printcount, pmc.sentcount, r.realname,
cs.comment_count, v.value AS votes
FROM node n
INNER JOIN radioactivity ra ON ra.id=n.nid AND ra.class='node'
INNER JOIN realname r ON r.uid=n.uid
LEFT JOIN node_counter nc ON nc.nid=n.nid
LEFT JOIN node_comment_statistics cs ON cs.nid=n.nid
LEFT JOIN votingapi_cache v ON v.content_id=n.nid AND v.function='sum'
AND v.content_type='node'
LEFT JOIN print_page_counter ppc ON ppc.path=CONCAT('node/', n.nid)
LEFT JOIN print_mail_page_counter pmc ON pmc.path=CONCAT('node/', n.nid)
WHERE n.type = 'blog' AND n.status = 1
ORDER BY ra.energy DESC
LIMIT 10

/*Nancy*/



*From:* Domenic Santangelo 
*To:* development@drupal.org
*Sent:* Mon, July 19, 2010 1:55:48 PM
*Subject:* Re: [development] MySql Performance Problem


On Jul 19, 2010, at 10:18 AM, nan wich wrote:


Can someone suggest ways to improve the performance?


First thing to do: indexes on the radioactivity, print_page_counter,
print_mail_page_counter and (possibly) votingapi_cache tables. I say
possibly on that one because I can't remember the behavior of that table
and if indexing it might decrease performance elsewhere.

hth,
D

Re: [development] &$node in nodeapi

[la...@garfieldtech.com]

On 10/4/10 4:01 PM, Pierre Rineau wrote:

On Mon, 2010-10-04 at 19:53 +0200, luca capra wrote:


The $op presave was my problem.

This is a syntax error
my_fill_cck(&$node );

and this should be my hook:

function mymod_nodeapi($node ...

because&$node is a pointer, and what I need is a reference (that is how
is passed an object ). It's right ?
Interesting, I learnt something new :)

Regards,
Luca


With PHP 4, objects where like any other values, copied when passed as
function parameter, which means any modification on the local copy
wouldn't be visible within the caller function. With PHP 5, you don't
have to add the&  operator to force the argument to pass by reference
because objects are always references (as we could see in other
languages such as python or java, or such).


Technicality: Without the &, you are passing by value.  Always.  The 
difference is that in PHP 5 what you are passing is a handle to an 
object rather than the object itself (not to be confused with a pointer 
as one sees in C/C++, as those don't exist in PHP).  So there's one 
object, but two variables of type "handle to get an object" that both 
point to the same object.


It's a very subtle difference that only bites you occasionally, but when 
it does it bites hard. :-)


The net result is the same: you need &$node to be compatible with PHP 4, 
but as of PHP 5 / Drupal 7 you don't want it anymore.


--Larry Garfield

Re: [development] Refresh rather than re-create D6 cache

[la...@garfieldtech.com]

Just to make sure, have you tried using the minimum cache lifetime on 
the performance page?  It essentially says that a cache record will 
always last at least that long, even if a clear is requested for it. 
That's your first step if you're finding some caches clearing too 
frequently (especially the expensive filter and page caches).


--Larry Garfield

On 10/18/10 5:22 AM, Tomáš Fülöpp (vacilando.org) wrote:

Hi,

In D6, after all caches are cleared, or after a lot of them expire and
get emptied by cron, the server load spikes seriously because all such
caches need to be re-populated.

Since this happens more and more on sites I work on, I have been
thinking about using another approach in my modules, in the sense that
caches would be /refreshed/ rather than cleared and re-populated. Each
cache refresh would run depending on e.g. a simple variable storing last
time stamp of any other cache refresh.

This would assure that a) all cached values would be available at all
times, b) caches would never be re-calculated all at the (near) same time.

I am about to write logic for this, but wanted to first check with
others in the list -- perhaps some of you know or can point to an
elegant solution that already exists.

Thanks!

vacilando

Re: [development] Refresh rather than re-create D6 cache

[la...@garfieldtech.com]

I... think I follow?  It sounds like you want an approach like the 
search index uses; when you tell it to rebuild the search index it 
doesn't truncate the index but marks all records as "dirty", so they get 
reindexed over time by cron.


You may also find this of use:

http://drupal.org/project/views_content_cache

--Larry Garfield

On 10/18/10 8:31 AM, Tomáš Fülöpp (vacilando.org) wrote:

Yes, Larry, I did experiment with that approach as well. It allows
caches to expire at different times, but a) you need to keep some sort
of approximate overview about the various expiration delays you're
setting (so that they don't have much chance happening at the same time)
and b) whenever such cache happens to expire, it still gets deleted at
cron and then will have to be re-calculated during the precious time of
page request.

Currently I am thinking about the following approach - crude pseudo code:

// Make sure no other cache has been started over defined period
* set buffer period between cache refreshes $cbuffer = 15 seconds
* if ( (time()-$lastcacherun) > $cbuffer )

// Check if the cache at hand has expired
* Set some cache life time $clife
* SELECT `created` FROM `cache` where `cid` = 'cachedobjectname'
* if ( (time()-$created) > $clife )

// Refresh the expired cache
* $lastcacherun = time()
* recreate cachedobjectname
* DELETE FROM `cache` WHERE cid = 'cachedobjectname'
* cache cachedobjectname using cache_set  with CACHE_PERMANENT

What do you think?






On Mon, Oct 18, 2010 at 14:34, la...@garfieldtech.com
<mailto:la...@garfieldtech.com> mailto:la...@garfieldtech.com>> wrote:

Just to make sure, have you tried using the minimum cache lifetime
on the performance page?  It essentially says that a cache record
will always last at least that long, even if a clear is requested
for it. That's your first step if you're finding some caches
clearing too frequently (especially the expensive filter and page
caches).

--Larry Garfield


On 10/18/10 5:22 AM, Tomáš Fülöpp (vacilando.org
<http://vacilando.org>) wrote:

Hi,

In D6, after all caches are cleared, or after a lot of them
expire and
get emptied by cron, the server load spikes seriously because
all such
caches need to be re-populated.

Since this happens more and more on sites I work on, I have been
thinking about using another approach in my modules, in the
sense that
caches would be /refreshed/ rather than cleared and
re-populated. Each
cache refresh would run depending on e.g. a simple variable
storing last
time stamp of any other cache refresh.

This would assure that a) all cached values would be available
at all
times, b) caches would never be re-calculated all at the (near)
same time.

I am about to write logic for this, but wanted to first check with
others in the list -- perhaps some of you know or can point to an
elegant solution that already exists.

Thanks!

vacilando

Re: [development] Refresh rather than re-create D6 cache

[la...@garfieldtech.com]

On 10/18/10 11:44 AM, Earl Miles wrote:

On 10/18/2010 8:25 AM, Pierre Rineau wrote:

hook_flush_caches() function description is quite clear on api.d.o, it
specifies that this hook should just return cache table names.


It is, but the current documentation does not match the name of the
hook. My belief is that the evolution of this hook happened late in one
of the cycles and it got changed to suit what was needed at that very
moment, rather than being done properly.


hook_flush_caches() was added post-D6 freeze to make good on a promise 
Dries made at a DrupalCon somewhere.  I forget if it was in the alpha or 
beta stage.


--Larry Garfield

Re: [development] barcode module for drupal

[la...@garfieldtech.com]

Hi, Mahesh.

Generally this list is not used for new module announcements.  There are 
far too many of those for it to be feasible. :-)  You should also 
consider releasing your module on Drupal.org[1] so that others can 
download it, extend it, and participate in its development.  Modules not 
on Drupal.org generally don't get noticed or used, as Drupal.org is the 
"central point of contact" for all things Drupal.


It looks like there are already some barcode modules[2] available, 
though, so you probably want to consider joining forces with one of the 
existing developers to reduce duplication, create a better module for 
everyone, and have less work yourself.


[1] http://drupal.org/cvs-application/requirements
[2] http://bit.ly/9mPL0r

Cheers.

--Larry Garfield

On 11/3/10 4:51 AM, Mahesh saini wrote:


Hello drupal developers,

i have developed a module for drupal.If you are going to organize an
event and want to allot icards to the users then with the help of this
module you can do this. or any e-commerce site want to generate barcode
slip for their product then they can use it to generate random barcode
slip.This module provide option to upload icard image on which user want
to print barcode.User can use default icard image as background image
provided with this module.This module provide widely used barcode
standard. Use this module and please give the feedback.
   If any of you have any idea to make this module better or any
suggestion to add functionality to this module; you are welcome. Its
just a start.There is still some work remaining.

===
WORK TO DO
===
1. Provide print option along with the barcode.
2. store the generated barcode in database so that when code value
obtained by scanning barcode can be matched.
3.barcode matching mechanism.

you can download barcode module here
:http://code.google.com/p/regbar/downloads/list
<%20http://code.google.com/p/regbar/downloads/list>

--
(\/)/\ /-/ ES /-/