I agree it can be handy to know when the decision was made to publish, but I think I’m stuck on the semantics. What you’re talking about sounds more like scheduledon or something.
To me, publishedon means the date it was published, which should be the pub_date. I would think publishedon would not be set until the document is in fact published, but again, that could be represented by the pub_date, so I still don’t understand the reasoning for both.
It feels the same to me as ’web users and manager users’, which are dropped in revolution. Why have both when they essentially represent the same thing.
I could understand renaming this to scheduledon and setting a value for it if the pub_date is set to some time in the future. I could also see adding scheduledby as well, to track who scheduled it, and then publishedby could be set to ’modx’ when the system changes the published state, or the default action of user id when it is published as a result of user interaction. Currently there is no way to tell if a user or modx itself actually published the doc, unless I am mistaken.
I’d be interested to know if this has been addressed at all in revolution?
This is a pretty speculative discussion since the variable names are used in a lot of existing code that would break if they were changed.
That said, I think a lot of confusion could have been avoided if they were named publishOn and unpublishOn rather than being put in the past tense. It’s confusing to say that something has a pulishedon date and an unpublished on date when both dates are in the future and an active verb phrase like "publishOn" is much more approriate for an action directive, which is what they really are. Using publishedon makes many people think that they’re recording when something happened, rather than advising MODx about when to *do* something.
To be fair, they *are* referred to with verbs in the user interface -- which ought to clue people in on what they are.
I don’t think this will change for 0.9.6, but it could be a possibility for MODx Revolution. I’m used to the current terms, but if you’d like to see them change -- click on the BUGS & REQUESTS link at the top of this page and suggest it as an improvement.
PS: If you can do it without insulting the developers of the current system, it will be more likely to be implemented.
Thanks BobRay, I could make the suggestion for Revolution. I certainly didn’t mean to suggest that field actually be renamed, although that is what I literally said.
Perhaps my Jr. Member status implies that I am new to MODx, inexperienced, and therefore shouldn’t be questioning in the manner i have? I certainly didn’t intend to be insulting to the developers at all if it came off that way. just questioning and thinking aloud. They have all done amazing work, and revolution looks very promising.
-
MODX Staff
- 2,502 Posts
Time to restate my original point.
The behaviour that I want is for modx to record a date/time in a field when it is published be it published now, future or past (yes people publish things in the past--especially when building out migrated sites from other CMSs).
My personal opinion is that the pub_date field take a value if one is not manually set by the poster.
If I write a page and check the publish box but don’t set a pub_date (since it would be unnecessary). modx would automatically set the pub_date with time() when the document is saved.
We don’t need to change publishedon since it really only ever is triggered when the document’s pub_date is reached (I think)
I can’t see how the addition of the behavior to the save of the pub_date would cause any problems. In addition, we could make it possible that it be a configuration selective behaviour to allow backward compatibility.
To sum up, I don’t think this behavior would be too hard to change. I may even look to see if it is something me and my cut-n-paste/hack-n-slash php skills can do and submit a patch with my existing Feature requesgt in JIRA.
Author of zero books. Formerly of many strange things. Pairs well with meats. Conversations are magical experiences. He's dangerous around code but a markup
magician.
Blog ✦
Twitter ✦
LinkedIn ✦
GitHub
Quote from: lucky at Nov 16, 2008, 12:59 AM
Thanks BobRay, I could make the suggestion for Revolution. I certainly didn’t mean to suggest that field actually be renamed, although that is what I literally said.
Perhaps my Jr. Member status implies that I am new to MODx, inexperienced, and therefore shouldn’t be questioning in the manner i have?
No, not at all -- sorry if it sounded that way. The MODx community welcomes constructive suggestions from anyone and it’s really valuable to find out where people run into problems in using MODx to meet their needs.
My comment wasn’t aimed at you in particular -- just a general caution based on observing how experienced programmers who are new to MODx sometimes suggest what seem to them like small changes without understanding the consequences or the reason things are as they are. I’ve been guilty of it myself.
Some people forget that when communicating with volunteer developers of an Open Source software project, it’s a lot more productive to adopt a tone that says, "would this be possible? It would really help me a lot," rather than one that suggests "this design is really stupid, here’s how it should be done."
Welcome to the community. We’re looking forward to your future input.
Quote from: smashingred at Nov 16, 2008, 08:33 AM
Time to restate my original point.
The behaviour that I want is for modx to record a date/time in a field when it is published be it published now, future or past (yes people publish things in the past--especially when building out migrated sites from other CMSs).
My personal opinion is that the pub_date field take a value if one is not manually set by the poster.
If I write a page and check the publish box but don’t set a pub_date (since it would be unnecessary). modx would automatically set the pub_date with time() when the document is saved.
We don’t need to change publishedon since it really only ever is triggered when the document’s pub_date is reached (I think)
I can’t see how the addition of the behavior to the save of the pub_date would cause any problems. In addition, we could make it possible that it be a configuration selective behaviour to allow backward compatibility.
To sum up, I don’t think this behavior would be too hard to change. I may even look to see if it is something me and my cut-n-paste/hack-n-slash php skills can do and submit a patch with my existing Feature requesgt in JIRA.
It sounds very reasonable to me (sorry if I side-tracked your thread at all). It should be quite doable with your plugin. I wish I had time to work on it right now.
After implementing something like this, you’d probably want to go back and manually set pub dates on your existing docs (if you haven’t already) so the site would be consistent.
BTW, how is your plugin failing? Did you set the plugin to listen to that event (on the System Events tab of the plugin)?
