the publish at / remove at function do not working in a new clean Umbraco 6.1.2 installation. I have set a publish date and time in the future (>10 Minutes) on an unpublished node, click on save (not save & publish) and wait. But after the publish time is gone the node is always unpublished. Has everyone this error, too? There are a solution to solve this?
I think I've seen an issue about this on the issue tracker here http://issues.umbraco.org - Please go and vote it up - If I'm wrong please feel free to create an issue and post the link in here so others who come across this issue and this post can go and vote on the issue.
I sound like a broken record here... but the entire "Please go vote it up" premise has to be one of the stupidest things I have ever seen.
As much as I love Umbraco, I have been very vocal as of late becuase the major parts of this project that are broken continue to stay broken. Depending on the small portion of the user base that frequents "our" to VOTE UP bugs is flat out stupid. At best it only favors those who have the time and energy to campaign for needed fixes. There are major bugs that get overlooked for years because nobody cares enough to go "vote them up".
Is it really too much to ask for one or more HQ or CORE team members to actually frequent this site (DAILY) and be responsible for driving communication with the other coders and managing the bugfix workflow then reporting back to the "our" members? This is the way most succesful software projects are run, closed or open.
The HQ and core team in fact does keep an close eye on the issue tracker and yesterday a newcommer to Umbraco got help fixing an issue by adding it to the issue tracker. So they are indeed watching the tracker daily.
A bug like the one above I'm confident will be fixed since it's pretty critical if one needs to make use of the member section so I'm confident this will be have a high priority and get fixed within the next release since this is a major bug.
Since last year where v5 got canned the HQ has done an insane amount of work to turn things around, which means that some things have been done a bit too quick at times. Therefore the HQ and Core team should slow down a bit and take the time to focus and making things stable and clean out major bugs and then prioritize accordingly.
The voting system can help to indicate, which bugs annoys most people but of course HQ and members of the core team will need to have a look at the filed reports and make a decision about the state of the bug (Is it critical, major, normal or easy). Some times the HQ/Core should however prioritize fixing many of the minor bugs, which at the moment seems to create most annoyance for site builders and editors.
But if people don't file the bugs on the issue tracker then the guys won't have a standing chance to know that something is not working.
I may be a bit naive but if no one is getting introduced to the issue tracker and the concept of voting up bugs it will certainly never get any better. That's why I try to encourage people to do it whenever I have the chance. Maybe I'm a one man army but at least I'm crazy enough to believe I can help change the world :) - But believe it or not there are many things that frustrates me as well and I'm trying to see what I can do about it to help the project. But as everybody else it's not always easy to find the time to do it.
But what would the better alternative to voting up things be? Companies that are gold partners (or have bought a confidence license) are entitled to have bugs fixed, which benefits all - Perhaps some gold partners should also be better at reporting bugs. But I don't know how else we can help the hq/core to figure out what to fix first and why?
I think that in the past year there have been a bit too many patch fixes because issues have not been found untill people started using the stable versions, instead of downloading the beta versions and give them a spin. This way many issues could have been fixed before the stable release. Perhaps this part of the cycle should be improved so testing is done more extensively before a stable release. Perhaps some comon scenarios should be setup and passed before a version can be released in a stable state.
So what would some good scenarioes be? What could the edge cases be in these scenarioes?
Umbraco 6.1.2 - publish at not working
Hi,
the publish at / remove at function do not working in a new clean Umbraco 6.1.2 installation. I have set a publish date and time in the future (>10 Minutes) on an unpublished node, click on save (not save & publish) and wait. But after the publish time is gone the node is always unpublished. Has everyone this error, too? There are a solution to solve this?
Best regards
Sören
Hi Sören
I think I've seen an issue about this on the issue tracker here http://issues.umbraco.org - Please go and vote it up - If I'm wrong please feel free to create an issue and post the link in here so others who come across this issue and this post can go and vote on the issue.
Cheers,
Jan
Hi Jan,
thank you! I have found this issue here and voted on it: http://issues.umbraco.org/issue/U4-2433
Sören
Hi Sören
Cool - turns out I have already voted on this particular issue myself :D
/Jan
I sound like a broken record here... but the entire "Please go vote it up" premise has to be one of the stupidest things I have ever seen.
As much as I love Umbraco, I have been very vocal as of late becuase the major parts of this project that are broken continue to stay broken. Depending on the small portion of the user base that frequents "our" to VOTE UP bugs is flat out stupid. At best it only favors those who have the time and energy to campaign for needed fixes. There are major bugs that get overlooked for years because nobody cares enough to go "vote them up".
Is it really too much to ask for one or more HQ or CORE team members to actually frequent this site (DAILY) and be responsible for driving communication with the other coders and managing the bugfix workflow then reporting back to the "our" members? This is the way most succesful software projects are run, closed or open.
Hi William
The HQ and core team in fact does keep an close eye on the issue tracker and yesterday a newcommer to Umbraco got help fixing an issue by adding it to the issue tracker. So they are indeed watching the tracker daily.
A bug like the one above I'm confident will be fixed since it's pretty critical if one needs to make use of the member section so I'm confident this will be have a high priority and get fixed within the next release since this is a major bug.
Since last year where v5 got canned the HQ has done an insane amount of work to turn things around, which means that some things have been done a bit too quick at times. Therefore the HQ and Core team should slow down a bit and take the time to focus and making things stable and clean out major bugs and then prioritize accordingly.
The voting system can help to indicate, which bugs annoys most people but of course HQ and members of the core team will need to have a look at the filed reports and make a decision about the state of the bug (Is it critical, major, normal or easy). Some times the HQ/Core should however prioritize fixing many of the minor bugs, which at the moment seems to create most annoyance for site builders and editors.
But if people don't file the bugs on the issue tracker then the guys won't have a standing chance to know that something is not working.
I may be a bit naive but if no one is getting introduced to the issue tracker and the concept of voting up bugs it will certainly never get any better. That's why I try to encourage people to do it whenever I have the chance. Maybe I'm a one man army but at least I'm crazy enough to believe I can help change the world :) - But believe it or not there are many things that frustrates me as well and I'm trying to see what I can do about it to help the project. But as everybody else it's not always easy to find the time to do it.
But what would the better alternative to voting up things be? Companies that are gold partners (or have bought a confidence license) are entitled to have bugs fixed, which benefits all - Perhaps some gold partners should also be better at reporting bugs. But I don't know how else we can help the hq/core to figure out what to fix first and why?
I think that in the past year there have been a bit too many patch fixes because issues have not been found untill people started using the stable versions, instead of downloading the beta versions and give them a spin. This way many issues could have been fixed before the stable release. Perhaps this part of the cycle should be improved so testing is done more extensively before a stable release. Perhaps some comon scenarios should be setup and passed before a version can be released in a stable state.
So what would some good scenarioes be? What could the edge cases be in these scenarioes?
/Jan
is working on a reply...