We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 5430
    • 247 Posts
    Just upgraded from 2.1 to 2.1.1 pl (running on LAMP server) and am experiencing some odd and frustrating problems. My form customization and access control pages don’t load, just get the resource tree and a blank page. Also, the pub_date bug from previous 2.0.X versions seems to have reappeared in this install, the pub_date setting will not save and it seems I can’t have a publishedon and pub_date setting at the same time. Client is peeved, any help would be appreciated.

    Couple things: I did clear my cache, I did flush all sessions and permissions before upgrading, I used cPanel’s filemanager for file removal and upload, I tried in different browsers, all the same.
      • 5430
      • 247 Posts
      The manager pages in question have miraculously started working again (no idea why, but I’ll take it), but pub_date isn’t working at all. I can store a pub_date entry if the document is unpublished, but once the date/time is reached, the document doesn’t publish. As soon as I publish the document manually the pub_date entry disappears. Am I the only one experiencing this problem with 2.1.1? Anybody?
        • 3749
        • 24,544 Posts
        The missing pages were probably a cache problem (either the MODX cache, or your browser cache).

        As for pub_date, there may be a bug, but be aware that resources can’t be magically published the instant the date and time are reached because MODX isn’t running unless someone visits the site (and I’m not sure if previewing from the Manager or viewing a resource in the Manager counts). The first person to visit the page from the front end of the site after the pub_date is reached should see the resource as published and it should appear in Wayfinder menus if the Wayfinder tag is uncached: [[!Wayfinder ...]]. If that’s not happening, it’s a bug.

        pub_date is only to set a future publish date for unpublished resources. It is always cleared when the resource is published, either manually or when the pub_date is hit -- so that’s normal. The publishedon field is set automatically when the resource changes from unpublished to published, so there’s no reason to set it if there is a future pub_date and it will be ignored in that case.

        The only reason Published On is editable is for the case when you want to mislead visitors about when a resource was published or correct an erroneous Published On date caused by accidentally unpublishing, then republishing a resource.
          Did I help you? Buy me a beer
          Get my Book: MODX:The Official Guide
          MODX info for everyone: http://bobsguides.com/modx.html
          My MODX Extras
          Bob's Guides is now hosted at A2 MODX Hosting
          • 5430
          • 247 Posts
          Quote from: BobRay at Jun 05, 2011, 10:44 PM

          As for pub_date, there may be a bug, but be aware that resources can’t be magically published the instant the date and time are reached because MODX isn’t running unless someone visits the site (and I’m not sure if previewing from the Manager or viewing a resource in the Manager counts). The first person to visit the page from the front end of the site after the pub_date is reached should see the resource as published and it should appear in Wayfinder menus if the Wayfinder tag is uncached: [[!Wayfinder ...]]. If that’s not happening, it’s a bug.

          The resources in question are entries in a video podcast, which are fed into an xml feed template via getResources. I would assume that visiting the feed URL, which triggers the getResources call (uncached), would qualify as a front-end visit, in which case pub_date isn’t effectively publishing the resource when it should.

          Quote from: BobRay at Jun 05, 2011, 10:44 PM

          pub_date is only to set a future publish date for unpublished resources. It is always cleared when the resource is published, either manually or when the pub_date is hit -- so that’s normal. The publishedon field is set automatically when the resource changes from unpublished to published, so there’s no reason to set it if there is a future pub_date and it will be ignored in that case.

          This has me a bit confused. I’ve been using pub_date in my feed for months, and it’s never cleared once the document is published, it stays in the database and shows up in the appropriate placeholder. Am I misunderstanding your comment? If I’m hearing you correctly, pub_date should be an empty field in the database the instant the document is published. This hasn’t been the case in the past, but perhaps THAT was a bug. I built this particular podcast feed in 2.0 and all the resources pre 2.1.1 show both the publishedon and pub_date fields as populated.

          Quote from: BobRay at Jun 05, 2011, 10:44 PM

          The only reason Published On is editable is for the case when you want to mislead visitors about when a resource was published or correct an erroneous Published On date caused by accidentally unpublishing, then republishing a resource.

          Yes and yes. I’ve run across frequent uses for having a different publishedon and pub_date set.
            • 3749
            • 24,544 Posts
            I could be wrong about pub_date, but my understanding is that it’s intended to be cleared when the document is published (and it sounds like that’s what you’re seeing now).

            I think you could make a case for letting users enter a Published On date at any point (even when creating an unpublished resource) and preserving it from then on, but I don’t think that’s how it works now and I think some users would prefer to have it change if a resource is unpublished and later republished or is automatically published via the pub_date setting.

            As for the bug, it could be a bug in the RSS code, which might be ignoring the pub_date setting and/or capturing the information before the document map is updated. Have you tested with a regular visit to the front end?
              Did I help you? Buy me a beer
              Get my Book: MODX:The Official Guide
              MODX info for everyone: http://bobsguides.com/modx.html
              My MODX Extras
              Bob's Guides is now hosted at A2 MODX Hosting
              • 5430
              • 247 Posts
              Finally getting back to this after some time out of town. I’ve dumped all the files, cleared every cache, reinstalled 2.1.1 and the problem persists. This isn’t an RSS issue. I have these same resource aggregated via getResources on a front-end page. Resources set with a future publish date/time aren’t appearing after that time has passed. Just tested this with a main page on the site that’s featured in the nav via Wayfinder. I set pub_date to 10 min in the future and it’s still showing as unpublished even after a few hours. I can’t think this would require a full day change, but will test that next I guess. It can’t be a getResources issue because Wayfinder is doing it too. This is very different behavior from what I was getting with pre 2.1 versions. Anybody have a comment on why things have changed? Any chance this is a local setting I’m unfamiliar with? This is the first time I’ve had trouble of this nature with any MODx version.
                • 22303 MODX Staff
                • 10,725 Posts
                I just tested publishing a Resource using a future pub_date and it worked instantly as expected. Can you provide any other information about the problem you are experiencing? Have you updated Wayfinder or set it’s cache property to 0? There was a bug in Wayfinder recently where it cached results and they were not being cleared with the rest of the cache.
                  • 5430
                  • 247 Posts
                  Bogus server time. Didn’t even think to check it, just assumed that couldn’t be it since it had been working fine. That’s what I get for going with cheap hosting. Looks like it’s working ok now. It is kinda frustrating that I can no longer store separate publishedon and pub_date settings as I was able to do in pre-2.1 versions, but it’s workable, and it makes sense. Thanks for the help.