Active
Project:
Node History
Version:
1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
29 May 2013 at 04:54 UTC
Updated:
20 Feb 2026 at 00:57 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
andypostNice idea
Comment #2
kscheirerWe need to get rid of that define() anyway.
Comment #3
kscheirerComment #5
andypostthis should have schema for introduced config https://drupal.org/node/1905070 and #1910624: [META] Introduce and complete configuration schemas in all of core
s/config/Drupal::config, see #1957142: Replace config() with Drupal::config()
Comment #6
kscheirerTalked with Crell, Drupal::config is not ok when we're in a namespace. Switched over in the .module file, trying to use the dependency injection for the views plugins.
However, this patch fails locally with "Declaration of Drupal\history\Plugin\views\field\HistoryUserTimestamp::create() must be compatible with that of Drupal\Core\Plugin\ContainerFactoryPluginInterface::create()". Not sure how it's incompatible though, they look pretty identical to me.
Hopefully someone else can run with it or let me know what's wrong. Still need to provide a schema for the config settings as well.
Comment #8
mstrelan commentedCan we fix the English of this comment at the same time?
See https://drupal.org/coding-standards/docs#drupal
Comment #15
danielen commentedI disabled currently only the cron job, because we want not to delete the information when user has read the node.
Patch works on 8.5.x
We should it make configurable via GUI in admin/config/content/history or similar.
If is that a need, it make sense to "redesign" the module so that the above can be configured.
Comment #16
danielen commentedComment #17
kscheirerIf there's a patch to review, status should be "Needs review".
Comment #18
danielen commentedThe patch is only a fix for those which doesn't want delete the history after 30day. "Make HISTORY_READ_LIMIT configurable" is not solved with that patch above
Comment #19
kscheirerAh, I understand, thanks. Should still be "needs work" then.
Comment #20
andypostfor patch #6
Comment #21
YurkinPark commentedRerolled for 8.6.x, also, i've checked other modules and services, changed there as well
Comment #23
YurkinPark commentedFixed some parts
Comment #24
YurkinPark commentedComment #26
andypostComment #27
andypostDo not cache config inside service
REQUEST_TIME is deprecated
Comment #28
YurkinPark commentedErrors and notes are fixed, also, i've provided post update to set config for existing instances.
Comment #29
YurkinPark commentedComment #30
savkaviktor16@gmail.com commentedComment #31
andypostthis is wrong - never store config object in protected properties
Do not store config object in protected properties
No reason to store value in protected property
REQUEST_TIME is deprecated
missing doc block
Comment #32
YurkinPark commentedRerolled and notes are fixed
Comment #34
vladbo commentedReroll for 8.8.x
Comment #36
vladbo commentedFixed tests
Comment #38
vladbo commentedAdded needed .yml files from #32 and removed irrelevant core update strings from #36.
Comment #39
vladbo commentedComment #40
joachim commentedMostly nitpicks:
I like this pattern! Is this documented anywhere as a way of adding injected services to something that might be used or subclassed elsewhere? I've create #3062100: document techniques for changing dependency injection in a backwardsly-compatible way to start a discussion about it.
Method vars should be snake case.
I feel this line would be more readable if the expressions on the right were assigned to variables.
We need to leave this constant in for BC, as custom code may be making use of it.
(Though I don't think there's a way to trigger a deprecation warning for a global constant?)
Whitespace.
Same here.
Though on second thoughts, this calculation is repeated at least twice. Could it be moved to a helper method getHistoryReadLimist() on a service somewhere?
Comment #41
andypostFix nits, btw it needs upgrade path tests (config could change in future so this upgrade should add only "read-mark" one)
Mean time it sounds like great candidate to foundation of
history.repositoryservice #2081585: [META] Modernize the History moduleComment #42
andypostNo reason to prefix config property as it already namespaced
Also it exposed issues in node and comment modules integration (no dependency on history one)
So it needs proper integration a-la
- is service history.repository exists and fall back to old default
- if exists call its method
PS: I think there's no reason to provide UI for this setting so it could be container parameter instead of config, so in rare cases when it needs override it will be overridable with settings.php or services.yml
Comment #43
vladbo commentedSeems like good idea. So if I got it right, we need to postpone current issue, re-roll #2081585: [META] Modernize the History module and then move
HISTORY_READ_LIMITtohistory.repositoryas container parameter.Comment #50
daffie commentedThe new config "mark_read" is in a lot of places directly swapped with the constant HISTORY_READ_LIMIT, only they are not the same.
We cannot just remove this constant. It need to be properly deprecated first.
Comment #53
quietone commentedThe History Module was approved for removal in #3336276: [Policy] Deprecate History module.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3520462: [meta] Tasks to deprecate the History module and the removal work in #3520468: [meta] Tasks to remove History module.
History will be moved to a contributed project after the Drupal 12.x branch is open.
Comment #55
longwaveComment #57
andypostReplaced
COMMENT_NEW_LIMITwithHISTORY_READ_LIMITas this constant unused by core for #3574661: Remove deprecated code from comments moduleComment #58
andypost