Custom widget not being "Published"

muppsy007 commented 6 years ago

SS4 with latest widget module installed. We have a custom widget for displaying a feed from a facebook wall. We have migrated this from SS3.x so I would say this is a case of us missing something important to do with SS4's new publishing system, but I can't find it when comparing to the Readme example.

What happens is when we view the page with the widget installed, the widget is not seen. Then I go through this weirdness:

Log in to CMS and refresh page, widget is still not shown
Navigate to page in CMS sitetee (just selected it) and refresh page - widget displays. NOTE: Save and Published not touched here
Navigate to another page in the CMS sitetree - widget still displays
Log out of CMS and refresh page - Widget disappears
Log back in to CMS and add ?stage=Stage to the widget page URL - Widget appears again

Any ideas what would be causing this?

<?php

namespace MySite\FacebookFeedWidget;

use SilverStripe\Forms\TextField;
use SilverStripe\Forms\NumericField;
use SilverStripe\Forms\FieldList;
use SilverStripe\SiteConfig\SiteConfig;
use SilverStripe\ORM\ArrayList;
use SilverStripe\View\ArrayData;
use SilverStripe\Widgets\Model\Widget;

/**
 * Defining the functionality of the Facebook Feed widget.
 *
 * @package widget_facebookfeed
 */
class FacebookFeedWidget extends Widget {

    private static $singular_name = 'Facebook Feed Widget';
    private static $description = 'Facebook Feed Widget';
    private static $plural_name = 'Facebook Feed Widgets';
    private static $table_name = 'FacebookFeedWidget';

    /**
     * Create the database fields for configuring the widget.
     */
    private static $db = array(
        'Heading' => 'Varchar(64)',
        'Limit' => 'Int',
    );

    /**
     * Provide meaningful default values - not possible for the ID.
     */
    private static $defaults = array(
        'Limit' => 5,
    );

    private static $show_status_messages = TRUE;
    private static $show_fb_id_only = TRUE;

    /**
     * Provide title and description to be used in the CMS.
     */
    //public static $cmsTitle = 'Facebook Messages';
    public function cmsTitle(){
        return _t('FacebookFeedWidget.TITLE', 'Facebook Wall Feed');
    }

    //public static $description = 'A list of the most recent Facebook messages';
    public function description(){
        return _t('FacebookFeedWidget.DESCRIPTION', 'A list of the most recent Facebook wall stream activity');
    }

    /**
     * Make the widget's configuration fields available in the CMS.
     *
     */
    public function getCMSFields(){
        return FieldList::create(
            TextField::create('Heading', _t('FacebookFeedWidget.Heading', 'Heading title on top of feeds')),
            NumericField::create('Limit', _t('FacebookFeedWidget.LIMIT', 'Maximum number of feed items to display'))
        );
    }

    /**
     * Fetch the messages from Facebook and make them available to the template.
     * The feed includes both your own posts and the ones from others. We are however only interested in our own posts, so we'll fetch some more and throw the others away.
     * Taking five more might not be sufficient, but we'll assume it's enough for our scenario.
     *
     * @return TODO: DataList containing all relevant fields.
     */
    public function Feeds(){
        // Do Facebook stuff
    }
}

rvowles commented 6 years ago

This is exactly the problem I am facing for all our widgets.

robbieaverill commented 6 years ago

Thanks. I’ve raised the impact level.

rvowles commented 6 years ago

We've got a call in with one of your account managers over this, its blocking our migration... Just to close the loop if they ask you :-)

martinheise commented 6 years ago

I have the same issue. Some insights:

The Widgets themselves are published correctly (records in _WidgetLive etc.)
but the WidgetArea of the page not published, Table _WidgetAreaLive is empty.
Creating a new page works including adding of widgets, WidgetArea is published.

So it probably looks like a migration issue with the has_one relation to the WidgetArea.

NightJar commented 6 years ago

but the WidgetArea of the page not published, Table WidgetArea_Live is empty.

Hi @muppsy007 - can you please confirm this case with your custom widget; is it the only widget on the page?

but I can't find it when comparing to the Readme example.

@muppsy007 Could you also please indicate whether you mean the Readme on this module, or perhaps one of the guides on migrations, etc?

NightJar commented 6 years ago

@muppsy007 @rvowles @martinheise You have all mentioned or alluded to this issue arising out of a recent upgrade to SilverStripe 4. Can you please give a brief rundown of the steps you've taken to upgrade this module?

@martinheise in particular you have made mention that all the widgets have published, could you please specify if you did this manually (whether via a build task or SQL query) or the system did it automatically for you on dev/build after upgrading?

@muppsy007 The steps you have described about signing in and out of the CMS simply change the viewing mode (as does ?stage=Stage) - this indicates to me that things are simply not published. @martinheise has confirmed my suspicions with his added info. Pre-SS4 neither Widget nor WidgetArea were Versioned - meaning that edits were instantly live. Now they are both Versioned, and ownership ($owns) is set up correctly. As a work around (or a fix, if you don't have too many pages with widgets) simply publishing the page should solve the issue for you in the meantime.

We would like to improve the migration experience however and address this on upgrade - as everything was 'always live' before there should be no issue in publishing both Widgets and WidgetAreas (however publishing pages automatically is dangerous as draft content generally should not be considered as OK to be live at the time of upgrade).

This may be as simple as making appropriate notes in the Readme - so it would be very helpful if you could all please provide feedback about your upgrade steps and experience :)

rvowles commented 6 years ago

My widgets also have nothing in WidgetArea_Live - which is where I suspected the problem lay. I could see them turn up in the Staging view, but never in the Live view. Publishing the page does not solve the problem, the widgets never turn up.

I have my v3 database as a docker image and regularly wipe it out and run the dev/build process - we have many CD environments with this in it so the upgrade needs to run smoothly through. If I can do anything that would help please let me know.

On Fri, Aug 10, 2018 at 10:04 AM Dylan Wagstaff notifications@github.com wrote:

@muppsy007 https://github.com/muppsy007 @rvowles https://github.com/rvowles @martinheise https://github.com/martinheise You have all mentioned or alluded to this issue arising out of a recent upgrade to SilverStripe 4. Can you please give a brief rundown of the steps you've taken to upgrade this module?

@martinheise https://github.com/martinheise in particular you have made mention that all the widgets have published, could you please specify if you did this manually (whether via a build task or SQL query) or the system did it automatically for you on dev/build after upgrading?

@muppsy007 https://github.com/muppsy007 The steps you have described about signing in and out of the CMS simply change the viewing mode (as does ?stage=Stage) - this indicates to me that things are simply not published. @martinheise https://github.com/martinheise has confirmed my suspicions with his added info. Pre-SS4 neither Widget nor WidgetArea were Versioned - meaning that edits were instantly live. Now they are both Versioned, and ownership ($owns) is set up correctly. As a work around (or a fix, if you don't have too many pages with widgets) simply publishing the page should solve the issue for you in the meantime.

We would like to improve the migration experience however and address this on upgrade - as everything was 'always live' before there should be no issue in publishing both Widgets and WidgetAreas (however publishing pages automatically is dangerous as draft content generally should not be considered as OK to be live at the time of upgrade).

This may be as simple as making appropriate notes in the Readme - so it would be very helpful if you could all please provide feedback about your upgrade steps and experience :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/silverstripe/silverstripe-widgets/issues/169#issuecomment-411912901, or mute the thread https://github.com/notifications/unsubscribe-auth/AADZ2HD-Enl50XTrKcMzNUOBPLkTxS0Rks5uPLICgaJpZM4TL6GA .

--

Richard Vowles, Full stack - from Kubernetes, through Node & Java, Web and Mobile development in Flutter - software developer for hire!

ph: +64275467747, web: www.google.com/+RichardVowles

NightJar commented 6 years ago

Thanks @rvowles Can you please tell me if you are using this module in conjunction with silverstripe/blog, or stand-alone on a custom Page type? And how is it that your automated migration runs?

rvowles commented 6 years ago

Standalone in custom pages - we don't use the blog module...

The automated migration runs by running "sake dev/build?flush=true" from the command line at start of the Kubernetes container. We haven't reached that far in this migration, I'm running it inside a VM with the database external.

On Fri, Aug 10, 2018 at 1:15 PM Dylan Wagstaff notifications@github.com wrote:

Thanks @rvowles https://github.com/rvowles Can you please tell me if you are using this module in conjunction with silverstripe/blog, or stand-alone on a custom Page type? And how is it that your automated migration runs?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/silverstripe/silverstripe-widgets/issues/169#issuecomment-411945683, or mute the thread https://github.com/notifications/unsubscribe-auth/AADZ2ANqupr0wlq_ephLMOrCHZkO8-BRks5uPN7LgaJpZM4TL6GA .

--

Richard Vowles, Full stack - from Kubernetes, through Node & Java, Web and Mobile development in Flutter - software developer for hire!

ph: +64275467747, web: www.google.com/+RichardVowles

NightJar commented 6 years ago

Thank you @rvowles Sorry could you please also advise me whether the Widgets themselves are published or unpublished after running the dev/build? I'm having trouble tracking down what could be performing this action. There does not appear to be any build task or migration script associated anywhere in silverstripe/widgets.

rvowles commented 6 years ago

They are unpublished.

On Fri, Aug 10, 2018 at 2:17 PM Dylan Wagstaff notifications@github.com wrote:

Thank you @rvowles https://github.com/rvowles Sorry could you please also advise me whether the Widgets themselves are published or unpublished after running the dev/build? I'm having trouble tracking down what could be performing this action. There does not appear to be any build task or migration script associated anywhere in silverstripe/widgets.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/silverstripe/silverstripe-widgets/issues/169#issuecomment-411954934, or mute the thread https://github.com/notifications/unsubscribe-auth/AADZ2AMHNpt73w-DE-H3rqm7n0xCzOuWks5uPO03gaJpZM4TL6GA .

--

Richard Vowles, Full stack - from Kubernetes, through Node & Java, Web and Mobile development in Flutter - software developer for hire!

ph: +64275467747, web: www.google.com/+RichardVowles

martinheise commented 6 years ago

@NightJar: Brief rundown of the steps to upgrade: I did follow the upgrade guide converting an old project, using mainly the single standard steps of uprgade-code. As the project was a bit messy I had to include some manual cleanup of composer requirements etc., including adding the removing old widgets module and adding the requirement to composer.json. But nothing directly database-related. Unfortunately I did notice the issue quite late when reworking my templates, so there could have been some editing etc. in the meantime.

Especially I didn’t touch the Widgets manually - the state mentioned in my previous post was the result of the normal upgrade and dev/build command. Also it was the same for all pages, even some quite sure I didn’t touch. (I’m curious if the issue is a bug inside the widgets module at all or rather in the Core).

More results from yesterday:

Simple republishing of pages didn’t solve the issue
Found then that the Version field of all WidgetArea records was set to 0

So this is how I could solve it for me finally:

Setting all WidgetArea/Version fields to 1 by SQL
call publishRecursive() on all staged WidgetArea records (maybe republishing the pages would have worked now)

NightJar commented 6 years ago

Interesting, thank you for the feedback @martinheise

While I certainly think it is possible to create a build task in this module to run after a code upgrade is complete in order to set the versioning to a correct state to begin with, I feel like there should be a feature for this in the core (possibly silverstripe/versioned) that allows for this kind of action as surely this isn't the only module affected.

It sounds like any object that was not versioned that becomes versioned will have issues adapting to that change. I think it would be cool if some of the core team could weigh in on this issue and give their thoughts - @robbieaverill @tractorcow @dhensby perhaps, as I know these people have dealt with versioning before.

My proposed solution would be to introduce a hook for e.g. Versioned that would run on a dev/build (akin to requireDefaultRecords) that would detect the absence of any versions in the ${DataObjectTable}_Versioned table, and automatically publish (recursively) the first version. This I think would be safe as previously to becoming versioned any update was instantly 'live', in a similar fashion to thinking of it as "permanently published".

grandcreation commented 6 years ago

Is there any way to temporary fix it? i cannot publish the page having custom widgets anymore :(

groundnation commented 6 years ago

Was having exact same issue i.e widgets (within blog) only showing with .../?stage=Stage, for me updating blog module fixed this, was using "silverstripe/blog": "^3.0@dev" - updated to "silverstripe/blog": "dev-master" and widgets now show properly.

ScopeyNZ commented 6 years ago

Was having exact same issue i.e widgets (within blog) only showing with .../?stage=Stage, for me updating blog module fixed this, was using "silverstripe/blog": "^3.0@dev" - updated to "silverstripe/blog": "dev-master" and widgets now show properly.

Hmmmn. I'm trying to understand why that would fix the issue and I can't figure out why... I agree with @NightJar that it seems like something that Versioned should be able to do on dev/build - When you add Versioned to some DataObject then it should create published versions of all the records. I'll do some more investigation and raise an issue on silverstripe-versioned.

robbieaverill commented 5 years ago

@ScopeyNZ

I'll do some more investigation and raise an issue on silverstripe-versioned.

Did this happen? I think we can move this to a versioned issue, I don't think it should be fixed here

ScopeyNZ commented 5 years ago

I haven't raised an issue but I do think it's a generic "adding versioned to something should create a published version of all those things". Something that should live on Versioned. I'll try to get around to putting some time to put my thoughts together in an issue today.

ScopeyNZ commented 5 years ago

Ok I've raised an issue... A few days after I said I'd try too 😅 ...

https://github.com/silverstripe/silverstripe-versioned/issues/215

I'll close this in favour of that. Thanks all for the discussion!

silverstripe / silverstripe-widgets

Custom widget not being "Published" #169

--

--

--