Hi,
Thanks for reporting the issue. I will release a version compatible with the PHP8 in the upcoming days.

Any Update on this? Looking to launch a site using this plugin in the next week and expected that purchasing and installing would be smooth.

Hi,
The new version will be at your disposal this week.

Plz, upgrade to the latest version. (9.0.1)

Have uninstalled and attempted to reinstall via the Extend Concrete Interface in the CMS. Still getting 9.0.0

Hi,
It could be the cache. You can try to upgrade tomorrow, or download the package and override it manually.

Hello,

I've gotten the Add-on to load now with 9.0.1.

I'm encountering an issue with simple .csv files not being read by the system now. This is a primary feature we purchased the Add-on for to maintain many data-driven tables. I upload a .csv to the file manager, I select it in the table and save, I view the table designer and no data is present. I've tried clearing cache and everything. No data is populating from the .csv file.

Please Advise.

When you choose a csv file to be used as the source of the table, the table designer logically becomes obsolete. Just try adding the table to the page, and you should see the table rendered by data inside the file.

Well, I guess the reason I'm asking is that nothing seems to be spitting out when using the CSV and I'm getting this error. Maybe a CSV parse error? I'm saving .csv files out of google sheets. They are pretty basic with just strings and numbers in there, no odd characters or snippets.

Getting these in Concrete Log

Would you either attach the css file to this thread or send it to me via private msg?

No problem!

Plz, upgrade to 9.0.2.
Cheers,

Still broken.

I go a page and enter edit mode. I add the table created with the attached file. I don't see anything display on the page after adding the block but it is there, empty and can be deleted. Just no HTML outputting.

Error hits the log as soon as I try to Publish a page with one of the table blocks on it.

Please advise. I have a site launching soon and this is getting down to the wire with this plugin not working.

Do you add the block via composer by any chance?

Could you tell me the line number for which the error happens in the add-on block controller?

Or if your site is online, could you send me your site credentials via private msg so I can take a closer look?

It doesn't seem to be throwing an error from the controller.php. At least I haven't seen any evidence of that like I'd be use to seeing in a block controller file.

It seems to be saving the table fine in composer as a block added to the page. The tables just displays as empty <table> tags in the page after publishing. Something is going wrong trying to parse the data out of the csv file. Maybe some odd character is thinking something is an array when it's not...?

"Array to String Conversion" seems to be the issue and it's happening I think at a more core level than the controller.php file.

FYI the tables render fine when using table designer data input.

I guess the process of elimination that my head is at right now is that there is some step that happens when I publish the page after adding a CSV-powered table.

Something is happening only at that step where I hit publish page. Is the package designed to read/write data at that exact step? That is the only action I've taken that produces an error in the CMS Error Log. It seems like upon publish, there is some sort of reading of the csv file that is failing due to some parse error of either the cell data itself or some sort of php object of the data, therefor firing a type error.

Looks like you've got a double array instantiation on lines 271/272 resulting in a [['850']] instead of just single ['850']. Perhaps that's it.

After removing the Array() instantiations from the $v declarations on both SQL queries, the error has stopped firing upon publishing. However, nothing is rendering still and I'm now not getting any errors at all.

When I remove the follwing line from controller.php->prepareItemsCSVFile(){
if (!in_array($file->getMimeType(), ['text/plain', 'text/csv'])) return;
}

I'm getting this error. So it looks like the CSV is never making the journey back to the php controller function that's calling for it. HTTP 401.

Any ideas?

Here is the error after it hits the php getURL()

It seems the error happens when using the block on the composer. I am going to release a new version in the upcoming hours.

Seems maybe that the controller.php doesn't have the proper permissions to request the file via HTTP 1.0.

I've done some testing around it and the file name/url is being pulled into the line...

new SplFileObject($file->getURL());

...just fine and at this point it is encountering a 401 Unauthorized error. I'm able to use the very same URL path to load the csv in my browser directly, so it's not protected in that way. I just think maybe something in the core CMS relationship with your Package's scope and permissions is having trouble loading the CSV file itself. into the code at this step so it's just reading blank.

I appreciate your time. A fix as soon as possible would be good as we launch later this week.

Thanks,
Cameron

Oh one other thing to mention, is that the csv MIME type out of some programs is not plain/csv, but application/csv, which is the case exporting csv out of google sheets for example.

This is the reason I wasn't seeing the 401 error until commenting out the MIME checking line. Once I added in the 'application/csv' MIME type to the check, it flowed down to the "new SplFileObject" line for the 401 error.

Cheers.

The 9.0.3 should address it.
Thank you for reporting and helping me to fix the issue.

Cheers,