Don't update log_online for certain actions

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Don't update log_online for certain actions
« Reply #15, on April 3rd, 2013, 08:05 PM »
Quote
And in this particular situation, there is no way for that to happen, so I'm asking you what your preferred solution(s) are...
I outlined two solutions I'd be happy with already.

Short of rewriting how the entire execution flow works, you can't fix it any other way, because what you're asking for is a way to selectively block logging based on a subaction while leaving the main action otherwise logged. But since execution doesn't get to handle subactions until after logging has already occurred, we have a problem in trying to support it like this.

Given that this is very firmly an exception rather than the rule, I don't really want to up-end a lot of code for the sake of an implied backward compatibility that isn't really that important in the grand scheme of things. Normally I'd be more inclined to support it but I'm not that worried here.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Don't update log_online for certain actions
« Reply #16, on April 3rd, 2013, 09:33 PM »
As an admin and user I am not worried about links changing. If I change software its my job to worry about forwards or letting people know to change their blasted links in their feed readers.
Thank you,
Boko

Nao

  • Dadman with a boy
  • Posts: 16,068
Re: Don't update log_online for certain actions
« Reply #17, on April 3rd, 2013, 11:51 PM »
Pete..? This is the 'best' I could come up with... -_-

index.php:236 (after $context['subaction'] is declared)

Code: [Select]
if ($action === 'media' && $context['subaction'] === 'feed')
{
global $action_no_log;
$action_no_log[] = 'media';
}

Very ugly. But, well... At least, it works. And it shouldn't have much impact on influence. (The only impact I'm afraid of would be the extra bytes to load for each index.php file if it's not being kept in memory, I'm afraid...)

I tried doing it the hard way -- moving Aeva-Foxy's feed code to Feed.php... First of all, it adds 10KB to the 25KB in Feed.php (meaning parsing the file is a bit longer when it's a fairly often accessed file...), then the Foxy code in itself is too tightly integrated with AeMe to 'make sense' in Feed.php, in my opinion... I may be wrong, but... I felt bad doing this, so I cancelled my changes.

Today sucked.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Don't update log_online for certain actions
« Reply #18, on April 4th, 2013, 12:36 AM »
Now you need to add a hook in there for anything else that wants to do the same thing. Creating an exception for the sake of (theoretical) backward compatibility also means creating a precedent and a means for everyone else to do the same.

Nao

  • Dadman with a boy
  • Posts: 16,068
Re: Don't update log_online for certain actions
« Reply #19, on April 4th, 2013, 08:42 AM »
I don't want to create a precedent... I just want to be done with this crap!
It's either this, or in QueryString I modify the query on the fly to read like action=feed;sa=media... And still redirect to Aeva-Foxy.php's feed handling somehow.
Oh well... I should probably simply do includes in the feed code. I'll look into doing that.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Don't update log_online for certain actions
« Reply #20, on April 4th, 2013, 04:12 PM »
Quote
I don't want to create a precedent... I just want to be done with this crap!
You're going to create a precedent by specifically writing exceptions.

Nao

  • Dadman with a boy
  • Posts: 16,068

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Don't update log_online for certain actions
« Reply #22, on April 4th, 2013, 07:26 PM »
I haven't actually looked at the commit yet. I'm still trying to get the infractions system done - it's only been gestating for over a year.

Nao

  • Dadman with a boy
  • Posts: 16,068
Re: Don't update log_online for certain actions
« Reply #23, on April 4th, 2013, 07:43 PM »
Look at it when you have a minute, and tell me if that's okay.
Considering I did multiple concessions in this one (including getting rid of the '.xml' to 'feed' action converter for SMF... That one was hard to part with >_<), if you're not happy, then you need to tell me...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Don't update log_online for certain actions
« Reply #24, on April 4th, 2013, 07:55 PM »
Quote
Considering I did multiple concessions in this one (including getting rid of the '.xml' to 'feed' action converter for SMF... That one was hard to part with >_<)
That sounds like a plan to me. No-one really worries about feed links when moving from other forum software to/from SMF, I see no reason why we are any different - it's not like we're really an SMF version any more.
Quote
Look at it when you have a minute, and tell me if that's okay.
OK, so quick look. Reusing the gallery code makes plenty of sense when pulled under the feed... and I can understand the need also to initialise it in a way the gallery would expect. Though it might mean a gradual overhaul of the gallery code in time, I don't know.

The reorganisation of manage plugins is fine, and the new hook is fine also though personally I might have called it feed_types since that's what it really is. But 'feed' is absolutely fine too.

On the subject of passing variables by reference, yes, technically we should probably update everything to not have & in it. However it is nice to leave them in to indicate what the rest of the code expects will be passed by reference; the problem is that hooks can dictate the rules themselves because the receiver indicates its nature rather than the caller. But if we indicate what should be passed, and how (because that intimates what is safe to change and what isn't) that should be OK too.

I seem to recall the determine_location hook only really being useful for pretty URLs because anything else would naturally just head to index.php through a conventional scheme. I dunno. It doesn't hurt to have it where it is though it does mean that even non-PURLs cases would go there too.

The feed compatibility with SMF was always one of those tricky things, as was the mgallery->media change. I personally don't feel a burning need to retain compatibility but that's just me. While SMF->Wedge is the obvious target for conversion, there will be conversions from other systems too and I don't see why they should be treated as second class citizens by comparison. The playing field should be kept level where possible.

I'm curious, why should $_GET be used explicitly for actions? There is one interesting circumstance, though I can't remember where it would ever be an issue, is that if both $_POST and $_GET were to provide an action, $_REQUEST would contain the $_POST version not the $_GET one.