Jump to content



Member Since 12 Aug 2015
Offline Last Active Aug 25 2017 08:38 PM

Topics I've Started

Addon.xml Settings - How Do I Reliably Return The Url Of An Uploaded File?

03 May 2017 - 05:49 PM

Using the <type>file</type> setting in addon.xml allows users to upload a file/image/etc using the Elfinder.


How do we get the file as a URL, or at least a URi? Calling registry just returns the relative path to the file that doesnt include higher folders, and it varies on accuracy.


For example, after uploading an image at "/images/companies/2/img.jpg" while in "all stores" mode, the registry (setting) for this field is saved as "companies/2/img.png". This is because in all stores there is a higher starting root of "/images"


Now if i do the same thing but in a storefront instead of "all stores" mode, the Elfinder root is now "/images/companies/2/". Uploading the file still goes to "/images/companies/2/img.jpg", but now the registry (setting) for this field is saved as "img.png".


I dont think CS is doing image pairing for this type of upload, and i didnt see any "generate a url with this image" functions that dont require image/object type or id.


Its pretty easy to do something like this if the setting comes from specific store:

$image = Registry::get('config.current_location') . '/images/companies/' . $company_id . '/' . Registry::get('addons.something.image');


But its not very accurate if someone puts it rando in "all stores" mode (ie, setting an image in an addon for all storefronts). Any ideas?

Data Structure - Registry Runtime.company_Data Vs Settings.company

27 April 2017 - 03:24 PM

In 4.3.4 (non multivendor), I'm noticing that there is both a "settings.company" object and a "runtime.company_data" object. One is obviously pulled from settings, but the latter runtime is pulled from various places in addition to settings. The thing im noticing is that runtime addresses, lang_code, countries_list, and others are wrong for store 1 (they use demo data) and are blank for stores 2 or higher.


Why are these fields not put into cscart_companies table (output as runtime.company_data)? Is this a bug in 4.3.4 or does this have to do with multivendor? Would it be safe to use a shim to mirror settings.company.XXXX into runtime.company_data.XXX (and vice versa) so the registry is, at least, consistent? Which is the preferred "future proof" method for getting company data? As it stands now, we gotta bounce back and forth between runtime and settings when it seems like all of that could be in runtime alone (or vice versa).


Im making an addon to sanitize+include missing data in registry, and this area of the object seems odd/inconsistent to me. Thanks for clarifying.

Custom Block Language Variable - Cant Figure Out This String

26 April 2017 - 03:18 PM

EDIT: Figured it out. Addons using scheme 2.0 don't use lang files for blocks. Sooooo to change the string below, it needs language_variable definition in addon.xml, named the same as the addon identifier. Such as:


<item lang="en" id="owl_carousel">Owl Carousel</item>



Original Q: We made a block for general Owl Carousel use. For now, it is applied to banners as a new display type (to compliment the slider style default carousel). Eventually i would like to apply it to other blocks as well. Its a simple addon -- just has a blocks.post.php schema, a carousel tpl, and a lang file (which i dont need minus 1 string).


Anyways, maybe its just morning brain fart, but I cant get a certain lang string to show up. This block is packaged as an addon, with its schema extending $schema['banners']['templates']. There is a lang PO file, but from what i am encountering here, its generated from something other than an identifier. I used the banners.po as a starting point, but similar strings are not found there either. I have attached a screenshot of the string in question. I tried adding "_owl_carousel" translation but that didnt do it either.

Addon.xml - How Do We Add A Standard Wysiwyg Textarea?

31 March 2017 - 08:42 PM

I don't see a straightforward way to add a WYSIWYG textarea via addon.xml without constructing it from scratch with the "template" item definition or hacking it in with a JS init. Is there a template somewhere i can include with various args to get a rendered WYSIWYG?


Ideally, it would be sweet to do right from addon.xml, so that there is no need to reference a template, nor reconstruct the control group stuff. Example, <type>wysiwyg</type> renders the correct goodies.


Or, if a template is required, a way to pull from something common like {include file="common/wysiwyg.tpl" id="addon_option_some_addon_setting" name="addon_data[some_setting]" rows="5" cols="19"}


This seems like a missing feature for addon devs. Thanks.

Settings/db Not Changing When Existing Addon Is Updated (Addon.xml Has New Settings)

24 March 2017 - 06:18 PM

We are trying to install an updated addon in CS-Cart 4.3.4 (yes we need to upgrade soon). An older version of this addon is already installed. Upon uploading a zip file, the files are updated in server, however its not acting right in the admin addon settings, and its not applying things from addon.xml to the database.


How do we percolate CS to re-up the addon.xml without uninstalling then reinstalling? The addon.xml has DB column drops, and I'm leary to comment them out to try the update in case there is some kinda db cached record that will apply the drops anyways.


Things i have tried:

 - Changing addon.xml to have a new version, priority, etc

 - Opening the addon area in a browser that has never visited that page before (never cached)

 - Clearing every CS-Cart cache i can find + storage + theme rebuild + redis + pagespeed + cloudflare + browser.

 - Disabling Cloudflare completely on the domain (in case it was somehow caching the addon settings popup)

 - Disabling the addon, uploading the update, enabling the addon

 - Various other disable/enables in specific multistore views

 - Renaming existing addon.xml to addon.xml.bak and trying an update

 - Combinations of this rename with disable/enables

 - Renaming and also removing the row in _addons DB table and reinstalling (new values were set, this is the closest i got, at least the new settings + DB stuff was saved -- but the settings popup wont change)

 - Visiting the addon settings popup directly and trying these things again (https://www.example....ddon=some_addon)


I have noticed this behavior in all addons. Its extremely frustrating when developing too, as you can't just add more settings into addon.xml and do a reinstall. It takes manual DB deletions or an uninstall first to percolate the changes.


Is this an issue with our version of CS Cart, or CS Cart in general? I didn't see anything addressing this in the changelog. Related topic: http://forum.cs-cart...3x/#entry269838