I'm curious to know if there's a specific reason that the foundation iparsys component forces the WCMMode to DISABLED instead of READ_ONLY (what I expected) before including inherited content? This behavior can be problematic for downstream components trying to figure out if they are in WCM or not (publish vs author).
I had to implement a work-around in my case to save the actual WCMMode before iparsys clobbers it for inherited includes, but this just feels like a hack. Perhaps I'm just going about this wrong? I have components that need to determine if they are in a runmode of author or publish, and have been checking against WCMMode.DISABLED to determine this. Is there a better way to check for the runmode?
I don't know why the iparsys uses disabled vs. runmode, but my experience is that WCMMode is not reliable if you are trying determine really determine author vs. publish reliably. If your code really has to work based on author vs. publish I would use the SlingSettingsService service to check the run mode.
SlingSettingsService settingsService = bindings.getSling().getService(SlingSettingsService.class);
Set<String> runModes = settingsService.getRunModes();
then iterate over the run modes and check for author.
I believe the reason for this is that it doesn't make sense to edit the inherited content in the context of the inheriting page (if that makes sense).
As orotas notes, WCMMode isn't really authoratative in terms of determining the runmode. It's really easy to specify ?wcmmode=disabled on the author node.
And, to be pedantic... runModes.contains("author") would be (slightly) more efficient (and easier on the eyes) than iterating of the runmode set.