BoldMinded

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: Bloqs are not being saved and displayed correctly

Status Resolved
Add-on / Version Bloqs 3.3.1
Severity
EE Version 4.0.4

AdriaanSnoeren.com

Jan 03, 2018

EDIT: If I save the entry without adding blocks all the blocks are gone, BE and FE

Description:
Running EE 4.0.4, Publisher 2.7.3, Structure 4.3.3 and Bloqs 3.3.1.

Detailed steps to reproduce the issue:
1. When saving an entry with a Bloq the first time the data is visible in the publish form
2. FE displays nothing
3. Editing the entry removes all blocks that were there and only adds the possibly newly added blocks, this is back-end
4. If I go front-end now all that’s being displayed are the blocks that aren’t visible in the back-end publish form anymore
5. So doing this again, adding some blocks and saving the entry only shows the newly added blocks in the publish form
6. FE only displays the blocks added in step 3…
7. And again…

I’ve got the feeling this has something to do with the Publisher settings but I don’t seem to find the right one.

Thanks again for helping out!

 

#1

BoldMinded (Brian)

Are you able to do me a favor and try to isolate it a bit? Backup your database and uninstall Publisher, then see if the issue still happens with Bloqs.

#2

BoldMinded (Brian)

Comment has been marked private.

#3

AdriaanSnoeren.com

Latest build has the same behaviour. Will work on the isolation now.

#4

AdriaanSnoeren.com

After disabling Publisher the Blocks seem to save fine back-end. Messes up the front-end though but I guess that’s not important. I provided you with a login to the dev env in the other ticket I submitted: https://boldminded.com/support/ticket/1628.

#5

AdriaanSnoeren.com

Comment has been marked private.

#6

BoldMinded (Brian)

Can you do me a favor and check your exp_channel_fields table for the bloqs field you added and see what the site_id value is for that field? It should be 1, but I’m betting you’ll see a 0 there.

https://www.dropbox.com/s/z8f73qxfnsaomjq/Screenshot 2018-01-04 19.00.08.png?dl=0

#7

BoldMinded (Brian)

Comment has been marked private.

#8

AdriaanSnoeren.com

Ok, I’ll try the builds now. Just checked the database. All my fields have site_id 0.

#9

AdriaanSnoeren.com

Comment has been marked private.

#10

AdriaanSnoeren.com

With the new builds installed and all site_id’s in exp_channel_fields set to 1 makes it work! Still wondering how the 0’s got there and got a 502 every time I changed the order of the blocks.

#11

AdriaanSnoeren.com

Sometimes (I think adding the first block after the update) the 502 appears also. For now it’s good enough for the client to start adding blocks because everything gets saved. Info on the 0’s would be appreciated as well to prevent this in the future. Thanks again!

#12

BoldMinded (Brian)

Comment has been marked private.

#13

AdriaanSnoeren.com

Comment has been marked private.

#14

BoldMinded (Brian)

Is there a stack trace with that? That is an odd error to be getting. Publisher tries to set the direction if the language is set to something other than rtl. It can be found in the Service/Handler/FieldHandler.php file line 170. You could try commenting that line out to see if it changes anything. I haven’t had issues with rtl or ltr in a long, long time.

#15

AdriaanSnoeren.com

Unfortunately I don’t see a stack trace with the error or in the debug info at the bottom. Commenting the line doesn’t make any difference.

The 502 is solved. FYI. I checked the logs in my dev environment and it read:

upstream sent too big header while reading response header from upstream

Solved by adding the following directives to the config:

proxy_buffers 8 16k;
proxy_buffer_size 32k;
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;

So it’s a server thing but it might help others here.

#16

BoldMinded (Brian)

Try adding this to the ft.text.php file at line 119:

https://www.dropbox.com/s/labf7o39loymsaw/Screenshot 2018-01-07 16.04.32.png?dl=0

if (!isset($this->settings['field_text_direction'])) {
         var_dump($this->settings); die;
        }

Then share the output. Maybe it’ll reveal what field is throwing that error.

#17

AdriaanSnoeren.com

That would be this:

array(14) { ["field_maxl"]=> string(3) "256" ["col_required"]=> string(1) "y" ["col_search"]=> string(1) "n" ["field_label"]=> string(5) "Title" ["field_required"]=> string(1) "y" ["col_id"]=> int(121) ["col_name"]=> string(5) "title" ["entry_id"]=> int(1291) ["grid_field_id"]=> int(58) ["grid_row_id"]=> NULL ["grid_row_name"]=> NULL ["blocks_atom_id"]=> int(58) ["blocks_block_id"]=> NULL ["blocks_block_name"]=> NULL }

Maybe some field in the database that shouldn’t be there but still is after testing..?

#18

BoldMinded (Brian)

I’m not sure what the issue could be to be honest. The only place Publisher cares about the text direction is the line noted in comment #14. Did you change the text direction? Or is this just happening regardless?

#19

BoldMinded (Brian)

I just checked locally and that setting is working fine. I changed my German language to ltr and it displays without error: https://screenshots.firefox.com/fJ7zYMSo8hrCZbDF/ee400.vm

#20

BoldMinded (Brian)

Adriaan, regarding the text direction error, re-save all your blocks that have Text fields in them, I think it’ll fix the issue. I have a fix in place for new installs, but existing installs have to re-save the block definition.

#21

BoldMinded (Brian)

The text direction issue has been fixed in Bloqs 3.3.2.

Login to reply