Closed vossisboss closed 1 year ago
@vossisboss #346 includes the Highlight block in the "to add" list. is that no longer needed?
Ah, I forgot about moving over the highlight block. That one would be useful too.
I'll remove all those blocks and clean up the migrations. Thanks again for the feedback!
@zerolab I think have cleaned up all associated templates and block definitions.
I tried removing the block definition for BackgroundColourChoiceBlock
as well since I don't believe we need that one anymore either, but the test server and the automatic migrations wouldn't run if I removed that one. There was an error AttributeError: module 'wagtailio.utils.blocks' has no attribute 'BackgroundColourChoiceBlock'
I'm not 100% sure why removing that one is different compared to the others that were removed. How did you check to see if the other blocks were used before you removed them? Checking the database?
BackgroundColourChoiceBlock is references in previous migrations. Let's leave it for now Go for staging
@zerolab I only have access to our production app. How do I push to staging?
So @zerolab, the staging branch hadn't been updated for a while. So I created a new one from main
and merged my changes to the new staging branch and deployed that branch to staging. I clearly borked something though because I'm getting a lovely 400 error. Any recommendations on which logs I should poke through for troubleshooting?
I think at this point we need to bring staging on par with prod. Will see what I can do about it
@zerolab Is there a reason we don't duplicate the data from production in staging beyond not wanting to pay to have the same data in two places? I see we have a smaller database for the staging app, so clearly we don't want to go nuts. But I think it would make testing things in staging a bit smoother if we at least had the homepage, the main page structure, some key snippets, and a couple of the blogs.
Would anything blow up terribly if I used one of the make
commands to pull the production data and media into staging? I could prune the amount of content down after the initial pull so that we don't have everything in there.
It should be ok to do so with the caveat we anonymise and non-essential users
I can remove all users except for an admin account if that sounds suitable to you.
I'm having trouble getting Fabric to work @zerolab. You can't run Docker commands without root access it seems, which is what the make
commands depend on, and I've tried installing Fabric individually as a package. The install script goes through, but then the package doesn't show up in the list when I either run pip list
or poetry show
. So the fab
command isn't available. Perhaps this has something to do with permissions or I'm not using the right directory?
Anyway, I might just go ahead and create some content to test the changes with and solve the problem of porting over content from production later since I haven't been able to get Fabric to cooperate.
All right. I did some test content and the blocks appear to be working they way they were intended to on staging. Unless there are any other tests or checks I should do, I would like to push this to production.
This PR is for cleaning up the blog blocks. We have a lot of blocks that were slated to be removed that are cluttering up the block chooser for StreamField. We also had blocks on the standard Content page that needed to be accessible in the blog.
I added three blocks to
StoryBlock
: Teaser Block, Get Started, and Sign-up formI created two new groups called "DO NOT USE" and "CTA options" to organise the blocks. I put all the old unsupported blocks in the "DO NOT USE" groups for now since I'm unsure how removing the blocks from
StoryBlock
will affect existing block content in the database and I suspect cleaning those blocks up properly will also involve making sure the existing content has a fallback-display option.If there are any good examples of retiring blocks, let me know. Otherwise, I think this solution will take care of most of our immediate needs for the blog.