Installed apachesolr as per instructions. Running Drupal 6.12 on centos os with PHP 5.1.6. OG installed so enabled Apachesolr OG integration. I also have taxonomy_access and og_subgroups modules installed as well.

Enabled a bunch of filters.

I did a search for "test". Got the default Drupal search results screen. Then, I clicked on the "Search" tab. Got the white screen of death. The httpd server reports these errors:

[Sat May 16 14:18:59 2009] [error] [client 192.168.218.3] PHP Fatal error:  Call to undefined function og_subgroups_get_eligable_groups() in includes/common.inc(1645) : eval()'d code on line 15, referer: http://mysite.com/admin/settings/apachesolr/index
[Sat May 16 14:23:13 2009] [error] [client 192.168.218.3] PHP Fatal error:  Call to undefined function taxonomy_admin_term_edit() in /includes/common.inc(1645) : eval()'d code on line 2, referer: http://mysite.com/admin/settings/apachesolr/index
[Sat May 16 14:44:06 2009] [error] [client 192.168.218.3] PHP Fatal error:  Cannot access empty property in modules/apachesolr/Zend/Json/Decoder.php on line 239, referer: http://mysite.com/search/node/test

So, I unchecked the following filters:

Apache Solr OG: Filter by Organic Group
Apache Solr Search: Filter by taxonomy ...

Re-indexed site. Re-ran cron.

Executed "test" search. Clicked on "Search" tab. No longer getting the errors. Search results come up as expected.

I would like to be able to use OG and taxonomy as search filters. Any suggestions for these? I find no reference to "taxonomy_access", "taxonomy_admin_term_edit" or "og_subgroups" when seaching apachesolr issues.

Comments

pwolanin’s picture

pwolanin commented

Well, the first error is likely due to some .inc file not being loaded when it's expected. Not sure what to do about that - probably a bug in og_subgroups

somebodysysop’s picture

somebodysysop commented
Title: white screen of death with taxonomy and og search filters » Invalid argument supplied for foreach() in taxonomy.module on line 1214

Found one of the problems!

The site I am testing was upgraded from 5.x to 6.x. I had some nodes that were php code format. A couple of those were used for testing, and, yes, called og_subgroups_get_eligable_groups() and taxonomy_admin_term_edit(). Hence the errors I posted here.

So, the solution to a problem like this in apache solr is not to have php code format nodes that call functions that no longer exist.

However....

I enabled the OG Filter. I deleted and re-indexed the site.

Once the site is indexed, and a search for "test" is executed, this fatal error is returned:

PHP Fatal error:  Cannot access empty property in modules/apachesolr/Zend/Json/Decoder.php on line 239, referer: http://mysite.com/search/node/test

I disable the OG filter, re-index site. Search for "test" works.

Any ideas on how I can fix this?

somebodysysop’s picture

somebodysysop commented
Title: Invalid argument supplied for foreach() in taxonomy.module on line 1214 » Cannot access empty property in Zend/Json/Decoder.php on line 239
pwolanin’s picture

pwolanin commented

The fatal error in Zend more mysterious - I have not really used the Zend code much other then a cursory initial test since I have PHP 5.2.

Do you have to re-index to make the error go away, or just turn off the module?

pwolanin’s picture

pwolanin commented
Title: Cannot access empty property in Zend/Json/Decoder.php on line 239 » Invalid argument supplied for foreach() in taxonomy.module on line 1214

The taxonomy module code is:

/**
 * Implementation of hook_nodeapi('update_index').
 */
function taxonomy_node_update_index(&$node) {
  $output = array();
  foreach ($node->taxonomy as $term) {
    $output[] = $term->name;
  }
  if (count($output)) {
    return '<strong>('. implode(', ', $output) .')</strong>';
  }
}

This is likely happening then when we call $extra = node_invoke_nodeapi($node, 'update index');

The invalid foreach says that $node->taxonomy is not an array - which it will not be for any node without taxonomy terms. To me this looks like a core bug.

indeed, here it is: http://drupal.org/node/225864

somebodysysop’s picture

somebodysysop commented

re: #5:

Sorry. I researched and found the same thing, which is why I changed the issue title. I realized it wasn't an issue with apache solr. For others following this, I used the temporary resolution http://drupal.org/node/259632 until it's fixed in core.

re: #4:

The fatal error in Zend more mysterious - I have not really used the Zend code much other then a cursory initial test since I have PHP 5.2.

Do you have to re-index to make the error go away, or just turn off the module?

If I uncheck Apache Solr OG: Filter by Organic Group, the problem goes away. Of course, so does the OG filter. Any guesses on the Zend error? Perhaps the index says a group is there that isn't? I don't mind plugging away on it, just don't have any clues right now.

pwolanin’s picture

pwolanin commented
Title: Invalid argument supplied for foreach() in taxonomy.module on line 1214 » Cannot access empty property in Zend/Json/Decoder.php on line 239

The title change was just due to cross-posting, didn't mean to change it.

pwolanin’s picture

pwolanin commented

Is this still a problem?

somebodysysop’s picture

somebodysysop commented

Yes, if OG Filter is checked I get this error:

PHP Fatal error:  Cannot access empty property in /modules/apachesolr/Zend/Json/Decoder.php on line 239
pwolanin’s picture

pwolanin commented

Intersting - I think I applied the "facet missing" trick to the OG sub-module, but I'm not sure what the JSON response actually looks like for that.

robertdouglass’s picture

robertdouglass commented
Version: 6.x-1.0-beta10 » 6.x-1.x-dev
somebodysysop’s picture

somebodysysop commented

Now getting this error on a different site where I have NOT enabled OG filter. Upon testing, it appears to happen when I enable "Filter by content type". Any ideas on what causes this under these circumstances? Has anyone else seen this and resolved it somehow?

By the way, I've tried to enable the og filter on 3 different sites now (all converted from 5.x to 6.x) and pretty consistently get this error. This is the first time I've received it for a filter other than og.

somebodysysop’s picture

somebodysysop commented

Any ideas whatsoever on this error when selecting "content type" filter?

UPDATE

It appears that I do:

This is a site converted from 5.x. For some reason, I had a series of nodes that had no content type at all (i.e., type field = ''). I deleted these nodes, and now the Apache Solr content type filter works.

However, the OG filter still does not work. But, this problem, and it's resolution, suggests to me that this is a content problem. But, what should I look for? I have 4 sites running now, including one which was created in 6.x. The OG filter does not work in any of them. In all sites, when the OG filter is enabled, I get the white screen of death on apache solr searches.

Anything at all I can try to look at?

pwolanin’s picture

pwolanin commented

SomeBodySysop: per above - try run the queries directly against Solr or logging the JSON response. This is almost certainly some difference in how PHP and the Zend class decode the JSON. It might be that you have to tweak the JSON class a little, or look around for an alternate JSON parser to try (search the back issue queue for one other option).

somebodysysop’s picture

somebodysysop commented

logging the JSON response

Not sure I understand how this is done. What I did do:

1. Went to apache solr screen (i.e., mysite.com:8983/solr)
2. Selected admin screen for one of the sites
3. Set the site logging to "finest" level
4. Ran queries from apache solr admin screen for site as well as from the "Search" tab in Drupal.

I ran 3 queries:

test
name
group
test group

Here is what popped up on my Linux console screen:

Aug 6, 2009 7:37:41 PM org.apache.solr.request.UnInvertedField uninvert
INFO: UnInverted multi-valued field {field=im_og_gid,memSize=4720,tindexSize=44,time=0,phase1=0,nTerms=3,bigTerms=0,termInstances=10,uses=0}

Aug 6, 2009 7:37:41 PM org.apache.solr.core.SolrCore execute
INFO: [test] webapp=/solr path=/select params={facet=true&facet.mincount=1&facet.limit=20&f.im_og_gid.facet.missing=true&json.nl=map&wt=json&version=1.2&rows=10&fl=id,nid,title,comment_count,type,created,changed,score,path,url,uid,name,im_og_gid,path,ss_filemime,ss_file_node_title,ss_file_node_url&start=0&facet.sort=true&q=name&bf=recip(rord(created),4,64,64)^200.0&facet.field=uid&facet.field=type&facet.field=im_og_gid&fq=(nodeaccess_all:0+OR+hash:bce391ff043d)} hits=1 status=0 QTime=22


Aug 6, 2009 7:40:04 PM org.apache.solr.core.SolrCore execute
INFO: [test] webapp=/solr path=/select params={facet=true&facet.mincount=1&facet.limit=20&f.im_og_gid.facet.missing=true&json.nl=map&wt=json&version=1.2&rows=10&fl=id,nid,title,comment_count,type,created,changed,score,path,url,uid,name,im_og_gid,path,ss_filemime,ss_file_node_title,ss_file_node_url&start=0&facet.sort=true&q=test+group&bf=recip(rord(created),4,64,64)^200.0&facet.field=uid&facet.field=type&facet.field=im_og_gid&fq=(nodeaccess_all:0+OR+hash:bce391ff043d)} hits=5 status=0 QTime=13

INFO: [test] webapp=/solr path=/select/ params={indent=on&start=0&q=test+group&version=2.2&rows=10} hits=5 status=0 QTime=10

This is what I found in /opt/apache-solr-nightly/drupal/logs:

192.168.218.3 -  -  [07/08/2009:02:34:41 +0000] "GET /solr/test/select/?q=group&version=2.2&start=0&rows=10&indent=on HTTP/1.1" 200 18551
192.168.218.3 -  -  [07/08/2009:02:36:23 +0000] "GET /solr/test/select/?q=name&version=2.2&start=0&rows=10&indent=on HTTP/1.1" 200 3090

127.0.0.1 -  -  [07/08/2009:02:37:41 +0000] "GET /solr/test/select?fl=id%2Cnid%2Ctitle%2Ccomment_count%2Ctype%2Ccreated%2Cchanged%2Cscore%2Cpath%2Curl%2Cuid%2Cname%2Cim_og_gid%2Cpath%2Css_filemime%2Css_file_node_title%2Css_file_node_url&rows=10&facet=true&facet.mincount=1&facet.sort=true&facet.field=uid&facet.field=type&facet.field=im_og_gid&f.im_og_gid.facet.missing=true&facet.limit=20&bf=recip%28rord%28created%29%2C4%2C64%2C64%29%5E200.0&start=0&fq=%28nodeaccess_all%3A0+OR+hash%3Abce391ff043d%29&version=1.2&wt=json&json.nl=map&q=name HTTP/1.0" 200 1403
127.0.0.1 -  -  [07/08/2009:02:40:04 +0000] "GET /solr/test/select?fl=id%2Cnid%2Ctitle%2Ccomment_count%2Ctype%2Ccreated%2Cchanged%2Cscore%2Cpath%2Curl%2Cuid%2Cname%2Cim_og_gid%2Cpath%2Css_filemime%2Css_file_node_title%2Css_file_node_url&rows=10&facet=true&facet.mincount=1&facet.sort=true&facet.field=uid&facet.field=type&facet.field=im_og_gid&f.im_og_gid.facet.missing=true&facet.limit=20&bf=recip%28rord%28created%29%2C4%2C64%2C64%29%5E200.0&start=0&fq=%28nodeaccess_all%3A0+OR+hash%3Abce391ff043d%29&version=1.2&wt=json&json.nl=map&q=test+group HTTP/1.0" 200 2954

I noted that I do get a xml response back in apache solr screen, but still white screen of death in Drupal. Is this info of any use, or am I supposed to be looking elsewhere?

Appreciate the response.

pwolanin’s picture

pwolanin commented

You could take the queries above and put them directly into Solr to get the JSON output. If you add &indent=1 the JSON will be much more readable. As an alternative, you could hack drupal_http_request() and add a watchdog or file_put_contents() in order to get the response out.

somebodysysop’s picture

somebodysysop commented

OK, thanks for your help. I may have found something here, but you'll need to let me know for sure, and what I can do about it.

I entered:

http://mysite.com:8983/solr/test/select?fl=id%2Cnid%2Ctitle%2Ccomment_count%2Ctype%2Ccreated%2Cchanged%2Cscore%2Cpath%2Curl%2Cuid%2Cname%2Cim_og_gid%2Cpath%2Css_filemime%2Css_file_node_title%2Css_file_node_url&rows=10&facet=true&facet.mincount=1&facet.sort=true&facet.field=uid&facet.field=type&facet.field=im_og_gid&f.im_og_gid.facet.missing=true&facet.limit=20&bf=recip(rord(created)%2C4%2C64%2C64)^200.0&start=0&fq=(nodeaccess_all%3A0+OR+hash%3Abce391ff043d)&version=1.2&wt=json&json.nl=map&q=test+group&indent=on

I get back:

{
 "responseHeader":{
  "status":0,
  "QTime":7,
  "params":{
	"facet":"true",
	"facet.mincount":"1",
	"indent":"on",
	"facet.limit":"20",
	"f.im_og_gid.facet.missing":"true",
	"json.nl":"map",
	"wt":"json",
	"version":"1.2",
	"rows":"10",
	"fl":"id,nid,title,comment_count,type,created,changed,score,path,url,uid,name,im_og_gid,path,ss_filemime,ss_file_node_title,ss_file_node_url",
	"start":"0",
	"facet.sort":"true",
	"q":"test group",
	"bf":"recip(rord(created),4,64,64)^200.0",
	"facet.field":["uid",
	 "type",
	 "im_og_gid"],
	"fq":"(nodeaccess_all:0 OR hash:bce391ff043d)"}},
 "response":{"numFound":5,"start":0,"maxScore":2.0780911,"docs":[
	{
	 "changed":"2009-07-17T23:51:44Z",
	 "comment_count":0,
	 "created":"2009-07-17T23:51:44Z",
	 "id":"bce391ff043d/node/67",
	 "name":"somebody",
	 "nid":67,
	 "path":"node/67",
	 "title":"Test Group II",
	 "type":"group",
	 "uid":1,
	 "url":"http://mysite.com/node/67",
	 "score":2.0780911},
	{
	 "changed":"2009-04-05T00:48:28Z",
	 "comment_count":0,
	 "created":"2009-04-05T00:48:28Z",
	 "id":"bce391ff043d/node/8",
	 "name":"somebody",
	 "nid":8,
	 "path":"node/8",
	 "title":"Test Group",
	 "type":"group",
	 "uid":1,
	 "url":"http://mysite.com/node/8",
	 "score":1.8662498},
	{
	 "changed":"2009-06-04T22:57:09Z",
	 "comment_count":0,
	 "created":"2009-06-04T22:57:09Z",
	 "id":"bce391ff043d/node/10",
	 "name":"somebody",
	 "nid":10,
	 "path":"node/10",
	 "title":"Test Group Page",
	 "type":"page",
	 "uid":1,
	 "url":"http://mysite.com/node/10",
	 "im_og_gid":[8],
	 "score":1.5464355},
	{
	 "changed":"2009-06-04T23:00:09Z",
	 "comment_count":0,
	 "created":"2009-06-04T22:58:32Z",
	 "id":"bce391ff043d/node/11",
	 "name":"somebody",
	 "nid":11,
	 "path":"node/11",
	 "title":"Test Filenode Page in Test Group",
	 "type":"filenode",
	 "uid":1,
	 "url":"http://mysite.com/node/11",
	 "im_og_gid":[8],
	 "score":0.9813734},
	{
	 "changed":"2009-04-05T00:50:36Z",
	 "comment_count":0,
	 "created":"2009-04-05T00:49:38Z",
	 "id":"bce391ff043d/node/9",
	 "name":"somebody",
	 "nid":9,
	 "path":"node/9",
	 "title":"Test Group Page",
	 "type":"page",
	 "uid":1,
	 "url":"http://mysite.com/node/9",
	 "im_og_gid":[8],
	 "score":0.86036664}]
 },
 "facet_counts":{
  "facet_queries":{},
  "facet_fields":{
	"uid":{
	 "1":5},
	"type":{
	 "group":2,
	 "page":2,
	 "filenode":1},
	"im_og_gid":{
	 "8":3,
	 "":2}},
  "facet_dates":{}},
 "highlighting":{
  "bce391ff043d/node/67":{
	"body":["  \n   Description:   \n <strong>Test</strong> <strong>Group</strong> II\n  \n  <strong>Test</strong> <strong>Group</strong> II  \n\n\n"]},
  "bce391ff043d/node/8":{
	"body":["  \n   Description:   \n <strong>Test</strong> <strong>Group</strong>\n  \n  <strong>Test</strong> <strong>group</strong>.  \n\n\n"]},
  "bce391ff043d/node/10":{
	"body":["  <strong>Test</strong> <strong>Group</strong> Page  \n\n\n"]},
  "bce391ff043d/node/11":{
	"body":["  <strong>Test</strong> Filenode Page in <strong>Test</strong> <strong>Group</strong>  \n    Filenode Operations        Download File Directly        Edit        \n\n\n   (edit)  "]},
  "bce391ff043d/node/9":{
	"body":["  <strong>Test</strong> <strong>Group</strong> Page.  \n  \n       Attachment    Size       \n  \n       newapp.pdf      63.42 KB     \n  \n  \n\n\n"]}}}

I'm guessing that my problem has to do with this:

"im_og_gid":{
"8":3,
"":2}},

Again, this is only a guess, but:

There are 5 search results. 3 belong to group id 8. 2 belong to no group (because they are groups themselves). Is it this empty group facet that could be causing the problem?

In Apache Solr OG configuration:
Is the group node "included" within a group along with that group's posts:
I selected "included" then "not included". I get the same exact results as above.

If the empty group facet is the problem, does that mean that the Apache Solr OG filter will only work on sites which only has group content? And, if that's not what it means, how do we address this problem of og filter searches returned with no groups?

Hope this makes sense!

pwolanin’s picture

pwolanin commented

I think you have to re-index to get a change to the included/not-included setting to have an effect.

somebodysysop’s picture

somebodysysop commented

Deleted index, re-indexed with the same white screen of death error.

This is the query from the log:

/solr/policy/select?fl=id%2Cnid%2Ctitle%2Ccomment_count%2Ctype%2Ccreated%2Cchanged%2Cscore%2Cpath%2Curl%2Cuid%2Cname%2Cim_og_gid%2Cpath%2Css_filemime%2Css_file_node_title%2Css_file_node_url&rows=10&facet=true&facet.mincount=1&facet.sort=true&facet.field=uid&facet.field=is_book_bid&facet.field=type&facet.field=im_og_gid&facet.date=created&f.created.facet.date.start=2009-08-07T19%3A11%3A36Z%2FHOUR&f.created.facet.date.end=2009-08-07T20%3A12%3A11Z%2B1HOUR%2FHOUR&f.created.facet.date.gap=%2B1HOUR&f.im_og_gid.facet.missing=true&facet.limit=20&bf=recip%28rord%28created%29%2C4%2C2%2C2%29%5E200.0&start=0&fq=%28nodeaccess_all%3A0+OR+hash%3A4d4335149b2e%29&version=1.2&wt=json&json.nl=map&q=test

And this is the resulting output:

{
 "responseHeader":{
  "status":0,
  "QTime":5,
  "params":{
	"facet":"true",
	"facet.mincount":"1",
	"indent":"on",
	"facet.limit":"20",
	"facet.date":"created",
	"f.im_og_gid.facet.missing":"true",
	"json.nl":"map",
	"wt":"json",
	"rows":"10",
	"version":"1.2",
	"f.created.facet.date.gap":"+1HOUR",
	"fl":"id,nid,title,comment_count,type,created,changed,score,path,url,uid,name,im_og_gid,path,ss_filemime,ss_file_node_title,ss_file_node_url",
	"f.created.facet.date.start":"2009-08-07T19:11:36Z/HOUR",
	"facet.sort":"true",
	"start":"0",
	"q":"test",
	"bf":"recip(rord(created),4,2,2)^200.0",
	"f.created.facet.date.end":"2009-08-07T20:12:11Z+1HOUR/HOUR",
	"facet.field":["uid",
	 "is_book_bid",
	 "type",
	 "im_og_gid"],
	"fq":"(nodeaccess_all:0 OR hash:4d4335149b2e)"}},
 "response":{"numFound":1,"start":0,"maxScore":0.30780494,"docs":[
	{
	 "changed":"2009-08-07T19:11:36Z",
	 "comment_count":0,
	 "created":"2009-08-07T19:11:36Z",
	 "id":"4d4335149b2e/node/1",
	 "name":"somebody",
	 "nid":1,
	 "path":"node/1",
	 "title":"Test Group",
	 "type":"group",
	 "uid":1,
	 "url":"http://mysite.com/node/1",
	 "im_og_gid":[1],
	 "score":0.30780494}]
 },
 "facet_counts":{
  "facet_queries":{},
  "facet_fields":{
	"uid":{
	 "1":1},
	"is_book_bid":{},
	"type":{
	 "group":1},
	"im_og_gid":{
	 "1":1,
	 "":0}},
  "facet_dates":{
	"created":{
	 "2009-08-07T19:00:00Z":1,
	 "2009-08-07T20:00:00Z":0,
	 "gap":"+1HOUR",
	 "end":"2009-08-07T21:00:00Z"}}},
 "highlighting":{
  "4d4335149b2e/node/1":{
	"body":["  \n   Description:   \n Group for <strong>testing</strong> group access\n  \n  <strong>Test</strong> group for <strong>testing</strong> access.  \n\n\n"]}}}

Same thing. Think that's (empty im_og_gid field) is the problem? If so, won't it be a problem with virtually every site?

pwolanin’s picture

pwolanin commented

most sites are on PHP 5.2, which has a built-in JSON decoding function that apparently behaves a little differnt.

If I pass your JSON above through PHP 5.2 json_decode I get for the facet count part:

    [facet_counts] => stdClass Object
        (
            [facet_queries] => stdClass Object
                (
                )

            [facet_fields] => stdClass Object
                (
                    [uid] => stdClass Object
                        (
                            [1] => 5
                        )

                    [type] => stdClass Object
                        (
                            [group] => 2
                            [page] => 2
                            [filenode] => 1
                        )

                    [im_og_gid] => stdClass Object
                        (
                            [8] => 3
                            [_empty_] => 2
                        )

                )

            [facet_dates] => stdClass Object
                (
                )

        )

Note that "" as a key in your JSON, gets turned into _empty_

somebodysysop’s picture

somebodysysop commented

I'm currently running php 5.1.6.

It sounds like you are saying that my problem would be resolved by running under php 5.2?

If so, I'll try to see if I can upgrade.

Thank you very, very much for your help here.

somebodysysop’s picture

somebodysysop commented
Status: Active » Fixed

I updated to php 5.2, enabled OG filter, executed search. No more white screen of death. Whoo-hoo!

Again, many, many thanks for all your help on this issue.

pwolanin’s picture

pwolanin commented

Yes, the Zend class is only used as a stop-gap for PHP 5.1, but still ti would be nice to know how to make it work right.

sixty4rpm’s picture

sixty4rpm commented

Yes, I agree with the last comment -- I am not able to upgrade to 5.2, and I am in desperate need of a workaround for php 5.1 and Zend/Json/Decoder.php. Is there any sort of simple fix? We really need to filter by OG.

pwolanin’s picture

pwolanin commented
Status: Fixed » Active

untested, but try changing the Zend code like so:

Index: Json/Decoder.php
===================================================================
--- Json/Decoder.php	(revision 5082)
+++ Json/Decoder.php	(working copy)
@@ -236,6 +236,10 @@
                 // Create new StdClass and populate with $members
                 $result = new StdClass();
                 foreach ($members as $key => $value) {
+                    if ($key === '') {
+                      // Mimic PHP 5.2 behavior
+                      $key = '_empty_';
+                    }
                     $result->$key = $value;
                 }
                 break;
sixty4rpm’s picture

sixty4rpm commented
Status: Active » Fixed

It's tested now! Thanks, works like a charm!

pwolanin’s picture

pwolanin commented

cross ref to ZF bug report: http://framework.zend.com/issues/browse/ZF-7586

pwolanin’s picture

pwolanin commented
Status: Fixed » Active

we should at least document this in the README

cfennell’s picture

cfennell commented

The PECL JSON extension operates in the same way as the Zend class, so perhaps a fix should be implemented higher up the food chain within solr-php-client, which is also where the failure actually occurs? With PECL JSON, you don't have much choice since you really can't modify it's source.

Transforming the _rawResponse variable w/in the constructor fixed the problem for me when using the PECL JSON extension.

//fix for PECL and Zend
$this->_rawResponse = str_replace('"":', '"_empty_":', $rawResponse);

Would it make sense to file an issue w/solr-php-client? It seems like other projects outside of Drupal would have run into similar issues, but I haven't done much digging outside of drupal.org. Anyway, I don't have much need for the og filter just now, so I'm disabling it.

jpmckinney’s picture

jpmckinney commented
Category: bug » support

I don't think it can be a bug if it has to do with Zend/PECL, etc.

pwolanin’s picture

pwolanin commented
Status: Active » Closed (fixed)

PHP 5.1 should be dead now. I think I put the patch above into the version we ship w/ Acquia Drupal