404 error for page view that was previously working when using an imagecache preset linked to a node in a field linked to a node

Just checked with the host, they haven't changed anything on that server in the last month.. so weird.

mmm, arguably that's a better way to do things if you're dropping in your view blocks with context. I was actually seeing this problem even when the view was a block.

The problem appears for me intermittently across multiple projects that I move from dev onto a shared hosting environment when they're approved for production.

I recently saw this problem again on a different project.

Having "link this field to the node" and selecting an imagecache preset linked to a node at the same time seems to be the problem. Removing the redundant linking fixed the problems.

baxang, can you check all your fields for suspicious link settings and report back?

csv? don't you need http://drupal.org/project/views_bonus for that to work out of the box? sure it isn't an issue with that module?

all the times I've seen this problem have been related to imagecache. Either the linking thing I described or not having a high enough memory limit on a shared server to generate my images and the out of memory error killed the view in a similar way.

you've tried poking around in the menu_links and menu_router tables?

do you have a local version of the site where you can replicate the problem? I know you said dpm() wasn't working but have you tried putting some in the core menu module to see if your paths come through there?

has anything changed recently in the server environment this site is hosted on?

This is a csv export right? so exporting the data in a useable way isn't going to be half as bad as trying to make something valid XML or an RSS feed.

Using Views is going to be heavy when you've got so many rows even if just because it calls tpl.php files for the View, for individual rows, and for each field.. Calling tpl.php files 4000+ times in a page load on shared hosting sounds pretty bad to me. Especially if you don't have anything cached and aren't running APC and generally can't control your server environment at all.

Here's something quick and dirty to try that shouldn't blow your memory like that and be relatively quick to implement. It might be enough, depending on what exactly is at "the other end" trying to read this export.

1. Create a new path with hook_menu with an callback function you'll use to render your CSV
2. Run the preview of your View, copy and pase the SQL query that is automatically generated by Views and displayed above the preview into db_query in your rendering function (and put curly brackets {} around the table names..)
4. Loop through the result in your rendering function and print the output rather than returning it
5. exit(); just after printing your CSV
6. Don't tell anyone you don't trust what your feed path is and don't hit it too often as I'm pretty sure you just broke Drupal's in-built caching (among other things) for that particular path

Ubercart (the gold standard of Drupal coding practice :P) actually does something a lot like this to display their "CCV info" popup on the checkout page while bypassing the Drupal theme system, so it works.. look at uc_credit_menu and uc_credit_cvv_info for an example

Anyway, I think we've figured out that your problem is unrelated to this issue so if you've got more questions, please open a new support ticket and reference it here.

Also you should expect that the size in bytes of the rendered output has little to do with the peak memory consumption in the process of rendering it... Imagine the memory required to resize and convert a 20MB png image into a 50kb jpg image on the server, it would be more than 50kb wouldn't it?

Please only post here if you're having *exactly* the problem described. I'm pretty sure there's a memory issue caused by an infinite loop or similar in the doubling up of creating links. If that's not the problem you're experiencing open a new ticket. You can reference this issue from yours if you want.

It's highly likely that what you're describing in #15 was caused by a corrupt system registry or cache, which are rebuilt when you go to the modules page. You probably moved the views module, or the module providing these particular views or something similar.

Reporting seemingly similar but probably unrelated issues in a single thread will basically guarantee they all never get addressed.