Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Bloq row doesn’t save: no Console or PHP errors thrown

Status Resolved
Add-on / Version Bloqs 4.5.1
Severity
EE Version 5.4

Paul Larson

Feb 08, 2021

A new bloqs install on EE 5.4 doesn’t seem to save rows. No errors of any kid.

I’ll elaborate further in private comments.

#1

Paul Larson

Comment has been marked private.

#2

Paul Larson

A follow-up clue:

It saves other bloqs that are on the same entry even, just not in the banner/slider.

Here is a screenshot of the particulars of the banner/slider.

https://www.dropbox.com/s/usp0yzapqy9j22y/2021-02-08_11-57-54.png?dl=0

https://www.dropbox.com/s/ywletacl04jw1yn/2021-02-08_11-58-54.png?dl=0

#3

Paul Larson

Specifically, i can create the bloqs without an issue and assign them into a channel. when editing an entry, the UI portion all seems to work without fault. It’s only when I try to save the entry that the banner/slider bloq field doesn’t save the data.

#4

BoldMinded (Brian)

Check your developer logs in the CP.

The error is b/c a block definition can’t be found. I suspect that you created an entry with a block, deleted that block entirely, or removed that block from the field’s setting, and are then trying to save the entry again? Or are you editing a revision? Regardless, it’s trying to find something that no longer exists, and I have no way of knowing what that is.

#5

BoldMinded (Brian)

The home page field does not have the Page/Banner Slider added to it. /admin.php?/cp/fields/edit/144

#6

BoldMinded (Brian)

Does this happen to brand new entries, or just trying to save an entry with bloqs already in it? I still think it’s related back to a scenario where the bloq was assigned to the field and no longer is, but the entry still thinks it contains that bloq so it doesn’t know what to do when it’s trying to save.

#7

Paul Larson

A quick recap of what I’ve gone through here in tracking down problems.

  1. uninstalled addon.
  2. reinstalled addon (starting from nothing in config)
  3. created some blocks
  4. created a bloqs field with new blocks
  5. assigned field to channel
  6. created entry
  7. added content to bloq field
  8. got this in dev log on save of entry: https://drive.google.com/file/d/1HMT18Y6tjwd-5v4cmbbT85se8dPYwicE/view?usp=drivesdk

Nothing has been removed from any of the blocks. The content itself seems to save in the entry, and the errors come up every time the entry is saved.

#8

Paul Larson

I take that back. It does NOT save all the entry data for bloqs fields. This is now holding up production.

#9

BoldMinded (Brian)

This is happening on the environment you entered into the ticket? If so what entry id should I look at?

#10

Paul Larson

It’s the “Home” entry - #272

page slider field won’t save changes to even the existing block. the page content field was saving changes to existing as well as adding blocks when I was last in the entry. Right now, it’s all fake data in that entry, so no reason to worry about saving it

#11

BoldMinded (Brian)

Paul, how do you feel about using the new/unreleased 4.6 version? There have been a bit of changes so debugging and fixing an “old” version for me is more time consuming.

#12

Paul Larson

Comment has been marked private.

#13

Paul Larson

Comment has been marked private.

#14

Paul Larson

ok, db backed up, new files uploaded, addon upgraded. all the same behavior

#15

BoldMinded (Brian)

I still can’t replicate this locally, and when that happens usually I ask the customer to create a new/fresh EE environment with only Bloqs installed and try to replicate the problem there. If the problem can’t be replicated in a new environment, that means there is something specific about the original environment that we’ll need to find. If you can replicate it in a new environment then that usually indicates a broader reaching bug.

In the current environment, add this to line 941 of PublishController.php

$this->_logger->developer('$blockDefinitionId: ' . $blockDefinitionId . '$block->definition->id: '. $block->definition->id .' '. json_encode($blockDefinitions));

So it looks like this

if ($blockDefinition === null) {
                $this->_logger->developer(sprintf(lang('bloqs_blockdefinition_missing'), $blockData['blockDefinitionId']));
                $this->_logger->developer('$blockDefinitionId: ' . $blockDefinitionId . '$block->definition->id: '. $block->definition->id .' '. json_encode($blockDefinitions));

                continue;
            }

Then lets see why it think it can’t find the block definition it’s trying to find.

#16

Paul Larson

Comment has been marked private.

#17

BoldMinded (Brian)

I still can’t replicate this locally. I have 3 bloqs fields in the same entry, some fields have different bloqs assigned to them, and they save fine every time.

Have you tried the clean EE environment?

Next comment has a new build that fixes the UI issue (bad css build file)

#18

BoldMinded (Brian)

Comment has been marked private.

#19

Paul Larson

Alright. In a fresh install environment with no other addons, things seem to be working. I will start adding the addons in to see what happens. and report back.

In the meantime, I tried to use the duplicate atom button while entering data. A Rich Text field was doubled in the UI: https://drive.google.com/file/d/1uDRLjr7YL0l9QtcF-4dmKTPyRYjPh440/view?usp=drivesdk

The content in the first was ignored and the second one’s data was saved. Possible UI/view issue?

#20

Paul Larson

When a wygwam field was used with the duplicate block button, the atom only appeared once. Previous screenshot may only be for native RTE fields

#21

BoldMinded (Brian)

Would you mind creating a new ticket for cloning issues with the RTE/Wygwam field? I’d like to track that separately.

#22

BoldMinded (Brian)

Sounds like the current status is re-creating the field “fixed” it?

#23

Paul Larson

Fresh install did work, yes.

Starting fresh, and rebuild the EE site would be a huge setback. So we’re still tinkering.

TL DR: Fresh fixes it. Moving our staging codebase to production gives us the same problem. So much for a different server fixing it!

#24

Paul Larson

Note: a 2nd blog, on the same entry, DOES work. It’s a simple RTE.

I’m currently removing fields from the more complicated blog, one by one, to see if I can rescue this.

#25

Paul Larson

Comment has been marked private.

#26

Paul Larson

Now where I am… it saves data, as you see…but it’s still sending messages to dev log

Bloqs unable to find the requested bloq definition with the ID #2.

Not sure if Dev Log is showstopper or not, if it seems to work.

#27

Paul Larson

Ok, made a brand new bloq , piece by piece, and get this upon entry save:

Bloqs secret key was invalid. 1 could not save entry #272. Field: 227 Session: 66f2e51ee2369eb24b4c81b8e8430b86 Post: 0134e86bdfdf371fc7a29541efd8413a

Bloqs unable to find the requested bloq definition with the ID #15.

BUT, this second bloq field also seems to save my edits.

#28

BoldMinded (Brian)

Don’t worry about that secret key thing, that’s old and I should prob remove it.

Is the site I have access to updates with the latest and greatest? Last time I looked at it the var dumps were still present and preventing saving.

You said it works fine one one sever but not another… so what is the difference? Php version? MySQL version?

#29

BoldMinded (Brian)

Can you provide ftp to the dev site?

#30

BoldMinded (Brian)

Unfortunately at this point I won’t be able to look into this again until Sunday or Monday night, but if you can provide ftp info to the server consistently showing those dev log errors it’ll help debug.

#31

Paul Larson

Sure can. I’ll post the creds and a video in a bit. Thanks!

#32

BoldMinded (Brian)

Try one thing for me, in PublisherController.php, line 897 is this:

if ($blockDefinition->id === $blockDefinitionId) {

change it to this:

if ($blockDefinition->id == $blockDefinitionId) {

And see what happens.

Someone else had a weird ass bug with Publisher that worked for me in multiple environments, and for other customers, but for some reason in his environment an ID was as string instead of an int, so the strict type comparison was failing. Wondering if that is what is happening with your environment too.

#33

Paul Larson

Comment has been marked private.

#34

Paul Larson

Comment has been marked private.

#35

Paul Larson

Trying your line 897 thing, sorry, Didn’t see that earlier!

#36

Paul Larson

Line 897 change had no effect. It throws “unable to find bloq definition” #16, for a brand new bloq that has no content tied to it.

#37

BoldMinded (Brian)

Paul, instead of using FTP, are you able to package up the whole site in a zip file, along with the sql dump so I can run it locally and step debug it? If so put a zip file containing everything on Dropbox or something, and be sure to remove any usernames and passwords from your config file for the db connection.

#38

Paul Larson

Comment has been marked private.

#39

Paul Larson

Comment has been marked private.

#40

BoldMinded (Brian)

Thanks for sending this, not sure I would have found a fix without being able to step debug locally. Talk about weird. I still can’t replicate this in my local environment, so I’m not sure what is specific to yours. I had both sites running PHP 7.4. Here is the issue explained:

https://www.dropbox.com/s/5hx3wrynjpwk6qx/ticket-2242-bloqs-multi-field-save.png?dl=0

#41

BoldMinded (Brian)

Comment has been marked private.

Login to reply