Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Recently I had to do some forensics on some stores. There is no timestamp to check when a store was created or modified to check when a store was created -- especially if having import issues.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 3029848-15.patch | 14.25 KB | jsacksick |
| |||
| #15 | new-store-admin.png | 414.97 KB | jsacksick |
| #12 | 3029848_store_form.patch | 10.57 KB | mkalkbrenner |
| |||
Comments
Comment #2
davps CreditAttribution: davps as a volunteer and at DrupalJedi commentedPatch contains next changes:
Comment #3
mglaman+1 at a quick review this looks correct. I'm at Decoupled Days and will try to find time to sit down and test it. I was going to add a "Needs tests" tag, but I'm not sure if it is worth testing these fields.
Comment #4
lisastreeter CreditAttribution: lisastreeter at Centarro commentedI wasn't able to apply the patch because of EntityDuplicateFormTrait. This is a simple reroll to fix that. No other changes.
Comment #5
lisastreeter CreditAttribution: lisastreeter at Centarro commentedAttempted to run database updates. Got an infinite loop with message: Division by zero commerce_store.post_update.php:98
I'm working on a fresh commerce install that does not have any stores yet. Update hook needs to account for that possibility to avoid division by zero bug.
Comment #6
mkalkbrennerI re-rolled the patch and removed redundant functions.
Comment #7
mkalkbrennerSorry, I made a mistake. Next try ...
Comment #8
mkalkbrennerThe patch is essential to get commerce stores to work better with default_content_deploy.
Comment #9
jsacksick CreditAttribution: jsacksick at Centarro commentedWriting a post update function to set the initial created/changed value isn't necessary. Also, not 100% sure this is what we want (i.e setting the created/changed timestamps to the current time).
But base field definitions have a way to specify the initial value (using the setInitialValue() method).
Comment #10
mkalkbrennerI just re-rolled the patch as it solves our problems;-)
How can we get a decision about the default value for existing stores?
Comment #11
mkalkbrennerI removed to post updates like discussed with jsacksick on slack.
Comment #12
mkalkbrennerAs discussed in slack, the StoreForm is now "similar" to ProductForm.
I also tested the form with existing stores after applying this patch. No exceptions and the created and changed dates will be set to request time on the first save. If you add the dates to a view they will simply have an empty value until the first modification happens.
Comment #13
jsacksick CreditAttribution: jsacksick at Centarro commentedIt kind of feels weird to show the current date as "last saved" when the changed timestamp is empty.
Also, probably make sense to have a 2 columns layout, just like products.
Note that
$this->timeis available.And, making the created editabledoesn't really make sense IMO.
Comment #14
jsacksick CreditAttribution: jsacksick at Centarro commentedComment #15
jsacksick CreditAttribution: jsacksick at Centarro commentedThe attached patch no longer exposes the "created" time in the form. Also, made the changes mentioned in #13.
The store form has now a secondary region, containing the tax settings, the supported countries.
I also added the store owner, below the last saved timestamp. And add the top of the region, the default store shows "Default store", see the screenshot below:
Comment #16
jsacksick CreditAttribution: jsacksick at Centarro commentedCommitted!
Comment #18
mkalkbrennerThanks. I like the new UI.