Remove ajax_footer()

Same here.

I'd prefer to port this conditional shutdown into onTerminate instead. Without doing so, there's a huge chance that we'll forget about that special case.

sun how do you see this happening? You have to register the onTerminate stuff and than it gets called automagicly. How do you define that the evenSubscriber only gets called on ajax requests?

We maybe can copy the same approach as with the viewSubscriber

     $negotiation = new ContentNegotiation();

      // @todo Make this extensible rather than just hard coding some.
      // @todo Add a subscriber to handle other things, too, like our Ajax
      //   replacement system.
      $this->dispatcher->addSubscriber(new ViewSubscriber($negotiation));
      ...
      $this->dispatcher->addSubscriber(new RequestCloseSubscriber());

We can pass negotiation to the closeSubscriber and than look if it's an ajax request and close it properly.
It's actually the same code as we have now on the terminate side only we should stop after "drupal_session_commit();" when we are dealing with an ajax request.

I'd simply move the conditional structures from ajax_footer() into the current, existing onTerminate(). No special-casing for Ajax.

Are you sure we still can run in that edge case with the kernel system?

if (drupal_get_bootstrap_phase() == DRUPAL_BOOTSTRAP_FULL && (!defined('MAINTENANCE_MODE') || MAINTENANCE_MODE != 'update')) {

I thought that on the moment we are in the terminate process the "DRUPAL_BOOTSTRAP_FULL" stage is always started.

drupal_bootstrap(DRUPAL_BOOTSTRAP_CODE);

$dispatcher = new EventDispatcher();
$resolver = new ControllerResolver();

$kernel = new DrupalKernel($dispatcher, $resolver);
$response = $kernel->handle($request)->prepare($request)->send();
$kernel->terminate($request, $response);

If I understand the symfony stuff the onTerminate gets called when we call terminate on the request.

And I'm not sure the maintenace mode stuff is needed either...

Hm. Well. Ok, let's just simply hope that something like http://drupal.org/project/js won't be required for D8 at all anymore (which is basically the reason for why most of these special conditions exist, since the idea of that is to use a completely custom js.php front controller that bootstraps... almost nothing. And with nothing, I literally mean it).

The state of the bootstrap is very confusing at the moment. We do /not/ run in a full bootstrap in the kernel. If you are running a legacy callback then you'll get the full bootstrap through LegacyRequestSubscriber. This can bite you if you're not aware of it.

As for your js project, you could do different bootstrap/request handling/front controller stuff by providing your own kernel and request handler. This actually provides you better control without weird special cases because you can control the entire stack. I do agree that hopefully we don't need it though.

+1 on the RTBC

drupal_cache_system_paths(). Away, once the menu system is ported to Symfony.
Module implements cache and cron run: These are the two things that we could/should try to avoid for AJAX requests, if possible. There is already a TODO to rewrite the whole onTerminate thing. I extended that, adding a note, that we should try to do lighter shutdowns for AJAX requests.

drupal_cache_system_paths() and module implements caching can both be got rid of by converting those respective caches to CacheArray (one has a patch, one will soon).

Cron is strange anyway, I don't see a particular reason to avoid that check on AJAX requests compared to on any other request.

@neclimdul doesn't the Kernel do DRUPAL_BOOTSTRAP_CODE? That's almost copy and pasted from DRUPAL_BOOTSTRAP_FULL so it's effectively a full bootstrap in the sense that required procedural code in /includes and all modules get loaded.

Yeah, BOOTSTRAP_CODE is basically BOOTSTRAP_FULL but checks like this against it fail. But they do only when going through index.php because non kernel bootstraps like the test runner still BOOTSRTAP_FULL. hense being a bit inconsistent and confusing.

Thanks. Committed/pushed to 8.x.

Sorry to reopen, there was still a call in ajax_deliver() to ajax_footer(), should be removed as well.

Ok, nevermind, #1622934: Replace delivery callbacks by leveraging the HTTP kernel, fix the overlay module is going to removed ajax_deliver().

I was working on a module update to D8, when I got the error 'call to undefined function ajax_footer'. I searched the change notifications, but didn't find anything, until I came here. Might be useful to make a change notification for this? Because it is unclear to me what should happen. Should developers just remove the function wherever they use it, or is there a replacement function/system?

I think they are all summarized in a single change notice?

Nevertheless, adding the API change tag, so this appears at least in the @drupalchanges stream (with status "fixed").

I searched for it But couldn't find it though. Or am I looking in the wrong place?

The central/summarized change notice is http://drupal.org/node/1635626

I do not think that this issue needs an own change notice, so reverting status to fixed.