Each item has publish info. You can use:
PublishInfoData publishInfoData = CoreServiceConnector.Client.GetListPublishInfo(item);
PublishInfoData class has the property PublishedAt, so you can filter there all for the last 24 hours.
So you can list every item in Tridion, get its published info, and then see if it was published somewhere in the last 24 ...
Why would you expect it?
Add binary method just adds binary to the package. Publish state is changed when item is published to delivery as a separate item and is present in broker db as Component Presentation.
AddBinary will not do that.
Up until Tridion Sites 9.5 you could publish Components in two ways:
Directly, if the Component has a "Dynamic Component Template." This is when you have a Component Template associated with the Schema for the Component and set to publish dynamically.
Indirectly, as part of the rendered content or added binaries of a page or other Component ...
Complimenting Marko's answer on the Event System, you could also look at extending Tridion CM search to store such information within the SOLR index as well. This way you can leverage existing infra and benefit from SOLR's powerful querying which can be executed via Core Service.
See Arjen's post: http://80000ft.blogspot.com/2012/08/search-indexing-handlers....
Another option, which might be a better one regarding performance would be to create Event System that would for each successful transaction send Transaction data to some custom storage (to some DB, or service). Then you can query that service periodically.
It would give you flexibility where you would not check all items in Tridion for their publish info, ...
You should be using TargetTypesFilterData. Something like this should work:
TargetTypesFilterData targetTypesFilterData = new TargetTypesFilterData();
var targetTypes = coreServiceClient.ClientInstance.GetSystemWideList(targetTypesFilterData);
To work with other Topology Manager items, you should be using Tridion.TopologyManager. Client.dll. You can find ...
This is a very curious requirement. But again, most of the business requirements are.
How I can see from your comments, you don't want to use the BluePrint for this which would be the proper case. I would in your case argue that the parent page should have general content and the child page should have general and specific content.
But if you do not want ...
The Publish Transactions you are adding in your event handler are before the original Publish Transaction, because your event handler triggers on the “Initiated” phase. That is: before the original Publish action executes.
If you want to add them after, you should subscribe to the “Processed” phase.
The Stack Trace pretty much tells you where the problem lies:
The error occurs in the PublishConfiguration TBB
It’s trying to publish “Localization Data”
For that purpose, it tries to determine the “Site Localizations” (i.e. related Publications in a BluePrint)
It tries to obtain a “Site ID” from a Publication.
This tries to construct a TOM.NET ItemFields ...
As Marko discussed, this is normal behaviour.
I do recall an old article from way back by Frank van Puffelen that discussed this and a Binary Event Tracker to allow these "implicitly published binaries" to show up as published/unpublished.
Its quite old so had to to dig it out via the Wayback Machine!