We upgraded a site today from 6.2 to 6.3, after the upgrade term pages could not longer be accessed via the system urls: taxonomy/term/tid, getting a 404. Tried directly and also from inside the category term list. Not seeing other reports on this, so assume its something funky in my setup. Anyone else experiencing this?

There are path aliases, for these term pages and we changed all the menus to use the aliases from their system urls... as a workaround.

CommentFileSizeAuthor
#14 views_debugging.txt46.75 KBMarcoF
#7 modules.txt1.67 KBcatch
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

Version: 6.3 » 6.x-dev
Priority: Normal » Critical

I've been getting this on 6.8. Same symptom - I can access terms via path aliases, but not via the system path directly. Bumping to critical. These pages have been refactored a fair bit in Drupal 7 with more to come, so it's unlikely the same bug is present.

I'm using views for taxonomy/term paths and pathauto to generate aliases. Are you also using views?

Gábor Hojtsy’s picture

Status: Active » Postponed (maintainer needs more info)

I think this should be a views issue. I do not remember changing anything around the term paths in Drupal releases. Also this happened on a 6.8 (catch) and 6.3 (gbear) setup, so it is not at all a recent change. It is either in the update process (where menu links are rebuilt) or much more likely views.

catch’s picture

Hmm, I just disabled the views override, did a menu_rebuild(), and still get a 404 in D6 (although not for every term path, just some). Additionally, taxonomy/term/n/0 works fine but taxonomy/term/n doesn't. So I'm not ready to move this to views just yet. I'll try stripping down to just core and see if it's reproducible there later on.

catch’s picture

OK here's a bit of tracking down.

Only on taxonomy/term/n and only some paths, in taxonomy_term_page(), $str_tids isn't getting passed in correctly, which means no operator, which means an instant drupal_not_found()

arg(2) returns an empty string '' but arg(3) returns NULL - this is because $_GET['q'] is 'taxonomy/term/' on those pages.

I'll investigate with all contribs disabled and post back. Leaving at active (needs more info) because it's extremely unlikely there's a core bug here, but there's not yet a specific contrib to blame either.

fgm’s picture

FWIW, cannot reproduce on a clean 6.8 install upgraded to 6.9. Maybe it results from an update_N prior to 6.8 : this issue would suggest 6.2 to 6.3

MarcoF’s picture

Hello, everybody.

I had the same problem upgrading from 5.5 to 6.8. Further upgrading to 6.9 didn't solve the problem. You can see it happen comparing http://storiafse.net/old/taxonomy/term/67 (Drupal 5.5) with http://storiafse.net/taxonomy/term/67 (Drupal 6.9)

I posted more details, before being told this is the right place, at the following URLs, so I won't write them again here:

http://drupal.org/node/356394
http://drupal.org/node/358739
http://drupal.org/node/345080#comment-1203774

My term_node table isn't empty and http://storiafse.net/taxonomy/term/67/1 (drupal 6.9) does show all the nodes filed under that term.
Please let me know by email or contact form if you want me to run some tests on the server to report here and (even more urgent, honestly) if and how I can fix that table myself, working with phpmyadmin or at the mysql prompt, whatever.

HTH,
M.

catch’s picture

Status: Postponed (maintainer needs more info) » Active
FileSize
1.67 KB

Chances are this is a contrib module interfering with with $_GET somehow, I don't think it's an issue with taxonomy.module itself - but that's probably the best place to track it.

If you could post the results of

SELECT name FROM system WHERE status = 1;

That'd be great - then we'll cross-reference them. Attached mine as a .txt

catch’s picture

Status: Active » Postponed (maintainer needs more info)

Didn't mean to change status.

MarcoF’s picture

Catch,

here you go:

mysql> SELECT name FROM system WHERE status = 1;
+--------------+
| name |
+--------------+
| block |
| comment |
| filter |
| help |
| menu |
| node |
| system |
| taxonomy |
| user |
| phptemplate |
| contact |
| forum |
| locale |
| statistics |
| throttle |
| tracker |
| upload |
| views |
| views_ui |
| dblog |
| php |
| update |
| views_export |
| marvin |
| bluemarine |
| garland |
| pushbutton |
| minnelli |
+--------------+
28 rows in set (0.00 sec)

In case this matters, this is a multisite installation (one common drupal, with one separate mysql database per site).
HTH. If you need more checks, just ask.

catch’s picture

Could you try disabling views module and see if that makes any difference?

MarcoF’s picture

Bingo.

If I disable the views modules I had active (views, views exporter, views ui, version 6.x-2.2 with drupal 6.9) the listing does come back.

You can check by yourself if you compare NOW http://storiafse.net/old/taxonomy/term/67 (Drupal 5.5) with http://storiafse.net/taxonomy/term/67 (Drupal 6.9) .

Of course, the "Indice cronologico" link in the left menu, which was a custom view, sorted by year, of all the nodes, doesn't work anymore, but views is surely part of the problem.

For the record, views _was_ active and working just fine (cfr the "indice" links in the old website) with Drupal 5.5

Now what? Still available for further tests, of course.

Thanks,
M.

catch’s picture

Project: Drupal core » Views (for Drupal 7)
Version: 6.x-dev » 6.x-2.x-dev
Component: taxonomy.module » taxonomy data
Priority: Critical » Normal

OK that's good. I'm sure I tested with views module disabled without having any affect, but might have just been an idiot that day.

Moving to the views queue now. Could you export any taxonomy related views you're using and attach the output as a .txt?

merlinofchaos’s picture

I got access to catch's site and database and figured out that something put a bunch of bad aliases in the url_alias table.

On catch's database, running SELECT * FROM url_alias WHERE src = 'taxonomy/term/' found hundreds of bad entries.

I can only theorize where these entries came from, perhaps some interaction between pathauto, cron and the update process.

MarcoF’s picture

FileSize
46.75 KB

This is what I've got from views->tools->bulk export, calling it views_debugging, but I'm not sure this is what you wanted. Please explain with more detail what you want me to do if this is the case.

M.

merlinofchaos’s picture

MarcoF's site currently has content on both pages, so it's hard to tell what's up there.

MarcoF’s picture

Project: Pathauto » Views (for Drupal 7)
Version: 7.x-1.x-dev » 6.x-2.x-dev
Component: Code » taxonomy data

That was because I had disabled the views module, as per Catch's suggestion.

With the views module disabled, the content appears. Now that I have enabled it again, you can compare the two pages, since the 6.9 ones are empty again. Just ask if you need more tests.

M.

catch’s picture

Project: Views (for Drupal 7) » Pathauto
Version: 6.x-2.x-dev » 7.x-1.x-dev
Component: taxonomy data » Code

OK, confirmed with merlinofchaos that this is in fact down to bad path aliases in the url_alias table.

SELECT * FROM url_alias WHERE dst like 'taxonomy/term/%';

Gave me 121 entries like:

+-------+----------------+--------------------+----------+
| pid   | src            | dst                | language |
+-------+----------------+--------------------+----------+
| 58608 | taxonomy/term/ | taxonomy/term/1179 |          | 
| 58601 | taxonomy/term/ | taxonomy/term/155  |          | 
| 58605 | taxonomy/term/ | taxonomy/term/156  |          | 
| 58611 | taxonomy/term/ | taxonomy/term/159  |          | 
| 58617 | taxonomy/term/ | taxonomy/term/1757 |          | 
| 58592 | taxonomy/term/ | taxonomy/term/1802 |          | 
| 58613 | taxonomy/term/ | taxonomy/term/1930 |          | 
| 58593 | taxonomy/term/ | taxonomy/term/1938 |          | 
| 58616 | taxonomy/term/ | taxonomy/term/2055 |          | 
| 58610 | taxonomy/term/ | taxonomy/term/2138 |          | 
| 58607 | taxonomy/term/ | taxonomy/term/2200 |          | 
| 58615 | taxonomy/term/ | taxonomy/term/2201 |          | 

I have a feeling some of my pathauto rules were a bit freaky immediately after upgrading from D5 - so these paths might have got caught in the gap somewhere.

MarcoF: if you could run that query, and post the results back here - also confirm if you're running pathauto, both during Drupal 5 and after upgrading to D6.

To remove the bad entries, just do

DELETE FROM url_alias WHERE dst like 'taxonomy/term/%';

But please post here first so we can track it down properly. Moving to pathauto as the most likely culprit, but still leaving as active (needs more info) until there's an identifiable bug.

MarcoF’s picture

Project: Views (for Drupal 7) » Pathauto
Version: 6.x-2.x-dev » 7.x-1.x-dev
Component: taxonomy data » Code

Here you go:

mysql> SELECT * FROM url_alias WHERE dst like 'taxonomy/term/%';
Empty set (0.00 sec)

I assume I wouldn't get anything anyhow by running "DELETE FROM url_alias WHERE dst like 'taxonomy/term/%';", now would I ? :-)

Path and pathauto are both disabled and so they were with Drupal 5.5 (I uploaded path_auto 2/3 days ago for another website on the same server, but haven't used it yet).

Since you're talking of paths, here's one thing that changed: in 5.5 I had clean urls disabled (couldn't make them work on the apache side, for some reason I don't even remember). Right after upgrade to 6.8, I found a page which explains how to set apache right, so I enabled clean urls. Does it help?

M.

merlinofchaos’s picture

Are you sure the view on that page is actually correct?

catch’s picture

Project: Pathauto » Drupal core
Version: 7.x-1.x-dev » 6.x-dev
Component: Code » taxonomy.module

Well that's a shame. I very much doubt enabling clean urls would have anything to do with it.

Can you do SELECT COUNT(*) FROM url_alias; for me?

MarcoF’s picture

@merlinofchaos:

"Are you sure the view on that page is actually correct?"

Yes, http://storiafse.net/old/taxonomy/term/67 (D5.5) is correct, that is, it shows just what I expect: all and only the stories filed under "Roma 5" by me and the other registered users.
Whereas on http://storiafse.net/old/taxonomy/term/67 (D6.8) you see the same listing only with the views module disabled. When it's enabled, as now, you only get an empty page.

@catch:

"Can you do SELECT COUNT(*) FROM url_alias; for me?"

your wish is my command :-)

mysql> SELECT COUNT(*) FROM url_alias;
+----------+
| COUNT(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)

In case this matters, I just checked and both the one above and the other query you asked me to do (SELECT * FROM url_alias WHERE dst like 'taxonomy/term/%';) yeld the same result on the 5.5 database.

M.

merlinofchaos’s picture

Just because it works in D5 doesn't indicate that the view you're using in D6 is correct. Views 1 and Views 2 are totally different pieces of software, and updating means doublechecking all of your views to make sure they work right.

MarcoF’s picture

"Just because it works in D5 doesn't indicate that the view you're using in D6 is correct."

The views which worked in D5 never worked in D6. I had to redo them from scratch. But the views are those in the "indice" links in the left menu (both in the old and new site).

whereas the stuff which is not working (the taxonomy/term/67 url) is not a view, is it?

Putting it in another way, isn't what we have here a case of the (mere activation of the) views module screwing up not just its own "products" but also other parts of the system?

M.

merlinofchaos’s picture

You had never indicated you don't have a view running taxonomy/term -- and Views comes with a default view (disabled normally) that does this. Perhaps you should check and make absolutely sure.

MarcoF’s picture

"You had never indicated you don't have a view running taxonomy/term -- and Views comes with a default view (disabled normally) that does this. Perhaps you should check and make absolutely sure."

you are absolutely right, sorry. Now I understand your earlier question. I had indeed enabled that taxonomy/term view (don't ask me why, please...).

Now that I have clicked on "Revert", http://storiafse.net/taxonomy/term/67 works just fine, showing all the nodes filed under that term.

Does all this help you guys to figure out the general issue?

Thanks, everybody!

M.

merlinofchaos’s picture

I'm guessing the general issue is that you had the taxonomy_term view enabled and not properly configured to actually be the taxonomy/term view. At this point since you have reverted that view, if everything is working now, you're basically ok?

MarcoF’s picture

Yes, I'm fine now, until the next time. By "general issue" I meant the one tracked in this thread, not the problem on my site only.

M.

merlinofchaos’s picture

catch's problem is something else entirely, and still need to get to the root, but I've gone as far with that one as I'm going to go. gbear's problem sounds the same as catch's.

catch’s picture

Yeah my issue was due to very strange path aliases that should never have existed under normal circumstances, which is a completely broken situation. Nothing to do with Views, possibly a pathauto upgrade path issue but if so it must be an obscure one.

catch’s picture

Found the pathauto issue #314697: taxonomy/term/[term-id] aliases point to system path /taxonomy/term/ although that's also elusive as to the actual cause.

dpearcefl’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

Closing this issue because of a lack of activity.