[Not a bug] Bug and error when adding music type product

[mc12345678]

The system timed me out and cut off my reply so here it all is again.

Page Source is showing the maxlenth as 8...

  <div class="form-group">
    <p class="col-sm-3 control-label">Products URL:<span class="help-block"><small>(without http://)</small></span></p>
    <div class="col-sm-9 col-md-6">
                <div class="input-group">
          <span class="input-group-addon">
              <img src="https://localhost/zc_158_bs/includes/languages/english/images/icon.gif" alt="English" title="English">          </span>
          <input type="text" name="products_url[1]" size="9" [B]maxlength="8" [/B]class="form-control" inputmode="url">
        </div>
        <br>
            </div>
  </div>

The developers tool kit turns up nothing when searching for maxlength="8" so I assume "8" is set by some other method, variable, function or constant.

It looks like collect_info.php calls on function zen_set_field_length (admin/includes/general.php) which in turn calls on function zen_field_length (includes/functions_general_shared.php) which in turn calls on $rs = $db->MetaColumns($tbl); (includes/classes/db/mysql/query_factory.php) and it polls the information schema for the number. 65535 is the maximum size since it is text.

That is as far as I can get in tracing down the problem...where and what is changing 65535 to 8?

I would like to know how the field maxlength is being set and if this is a bug or not. It is a bug to me because I can not manually type the products url in the admin product page.

Thanks.

What about the database? Is it a blank or demo database?

As described, the issue is that you are getting to line 995 from the following:
https://github.com/zencart/zencart/b....php#L967-L997

The default database type for products_url in the products_description table is:

  products_url varchar(255) default NULL,

Not "TEXT" as described in the above. As a result, there is no "default" size returned because the aforementioned code section does not account for all possible datatype that might exist, but rather those designed into use and further refined for Zen Cart purposes or discovered as an issue. Why? Because of the development path decided, provide mostly the minimum necessary for the base code, those that make changes need to incorporate/modify what is needed to do what they are doing.

[mc12345678]

Three ways I see to resolve the identified issue:
Modify your admin/includes/modules/product_music/collect_info.php file to remove the set field length command.
Add an observer to account for this field/fieldtype.
Modify includes/classes/db/mysql/query_factory.php to account for that field type to return the size applicable for that datatype with the possibility that it might be different in different environments. (Last part started because I haven't researched if the aforementioned large size is uniform across all associated environments.)

Only the last is likely to lead to request of a PR against the code.

[mc12345678]

Three ways I see to resolve the identified issue:
Modify your admin/includes/modules/product_music/collect_info.php file to remove the set field length command.
Add an observer to account for this field/fieldtype.
Modify includes/classes/db/mysql/query_factory.php to account for that field type to return the size applicable for that datatype with the possibility that it might be different in different environments. (Last part started because I haven't researched if the aforementioned large size is uniform across all associated environments.)

Only the last is likely to lead to request of a PR against the code.

Oops, fourth possibility is to modify the field type of that field to one that would be processed to give the max field length desired, though may be issues with doing that.

[mikeel100]

Hmm, that's bizarre. Let me poke around a bit and see if I can come up with anything in the morning.

Update: Just saw your previous post. When you view the products_description table, via phpMyAdmin, what's the configuration for the products_url field?

Text , utf8mb4_general_ci , NULL Yes , Default NULL

And this may be all my doing...

My admin installer script file modifies that field.

$sql = "alter table " . TABLE_PRODUCTS_DESCRIPTION . " change `products_url` `products_url` text character set " . DB_CHARSET . " null default null ";	
$this->executeInstallerSql($sql);

Let me change the field back to original and see what happens...

$sql = "alter table " . TABLE_PRODUCTS_DESCRIPTION . " change `products_url` `products_url` varchar(255) character set " . DB_CHARSET . " not null default '' ";	
$this->executeInstallerSql($sql);

Uuuuuuugh

[mikeel100]

That appears to have done the trick for my Music page...have not tested any others.

Thanks for pointing me in the correct direction and so sorry for wasting your time.

[mikeel100]

FYI...my admin plugin modifies that field, and others, because my datafeed has image filenames, product names, manufacturers names, metatags_descriptions and names, category names and URLs longer than the default settings for the database at install.

Can you increase the db install file field sizes to a higher setting for image filenames, product names, manufacturers names, metatags, category names and URLs.

My shop had 100,000 products in it and I had to do some extraordinary things to speed up page loads.
- I could not put all images in one folder...had to create 4 deep categories (thus the long path names)
- My supplier changed to cloud based images so some of my URLs were lengthy and getting chopped off
- The home page would take forever to load so I changed the landing page to a specific category that had a few products in it...and eventually created and automated the landing page to be a random category or subcategory from over 2000 categories.
- I also made the side and center boxes randomize products for the category being viewed
- Too many to go into full detail on here...

I had to change a few fields from varchar to text.

Hopefully, none of my other admin plugin changes will affect how the cart works but I will review my install script file again...maybe comment out all field alter changes and see how everything works out.

Thanks again.

[mikeel100]

The default database type for products_url in the products_description table is:

  products_url varchar(255) default NULL,

Not "TEXT" as described in the above. As a result, there is no "default" size returned because the aforementioned code section does not account for all possible datatype that might exist, but rather those designed into use and further refined for Zen Cart purposes or discovered as an issue. Why? Because of the development path decided, provide mostly the minimum necessary for the base code, those that make changes need to incorporate/modify what is needed to do what they are doing.

Thanks for the clear description of what happened.

When @lat9 asked the question about the field settings, I remembered the my admin plugin scripted installer file affected that field.

Now that I know what altering a field can affect, I will think twice about changing them in the future.

My bad....

[mikeel100]

What about the database? Is it a blank or demo database?

As described, the issue is that you are getting to line 995 from the following:
https://github.com/zencart/zencart/b....php#L967-L997

It was demo initially, then my admin plugin was used to delete the demo data then load 89,759 products to the database.

[mikeel100]

Three ways I see to resolve the identified issue:
Modify your admin/includes/modules/product_music/collect_info.php file to remove the set field length command.
Add an observer to account for this field/fieldtype.
Modify includes/classes/db/mysql/query_factory.php to account for that field type to return the size applicable for that datatype with the possibility that it might be different in different environments. (Last part started because I haven't researched if the aforementioned large size is uniform across all associated environments.)

Only the last is likely to lead to request of a PR against the code.

I understand the first...the rest are way over my head. LOL

[dbltoe]

Just a thought. In some cases, they don't work but, have you tried converting the long URL's to something like tinyurls?

https://tinyurl.com/app?gclid=Cj0KCQ...gaApzDEALw_wcB



I know it looks rediculuous to have such a long URL for a system designed to shorten them but they won't let that URL be shortened. Try one an test if it will actually work with those cloud images.