GetSimple Support Forum

Full Version: Catalog Plugin
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
Does I18N/Core GetSimple handle such titles with proper transliteration? If I create a regular page with a Hebrew title, it just gives me the slug 'temp' or 'temp-#', where # is a number (and it uses the code you just showed). Are you okay if I implement it that way (with a predetermined slug, e.g. product-TIMESTAMP), or are you expecting a more unique string?

It is either that or hard-coding the transliteration options for other languages in the i18n hash as you've shown above (is there one for Hebrew in GS?).
(2015-01-17, 06:53:30)Angryboy Wrote: [ -> ]Does I18N/Core GetSimple handle such titles with proper transliteration? If I create a regular page with a Hebrew title, it just gives me the slug 'temp' or 'temp-#', where # is a number (and it uses the code you just showed). Are you okay if I implement it that way (with a predetermined slug, e.g. product-TIMESTAMP), or are you expecting a more unique string?

It is either that or hard-coding the transliteration options for other languages in the i18n hash as you've shown above (is there one for Hebrew in GS?).

I18N does handle the titles, for proper transliteration try my commit @ git
and add i18n transliteration to your lang file (see http://get-simple.info/forums/showthread...9#pid49319 )
each lang (or user) can have it's (or his) own transliteration
Just installed latest commit in clean install of GS3.3.4:

1. Image Picker for both Products and Categories does not have scrollbar.

2. Image Picker for Categories will not select image.

3. Hitting Save in Settings/Theme or Settings/Fields throws an error:

[Image: GSCatalog-save-error.jpg]

but save does work ok on Settings/Settings or Settings/Cart.

4. If Image Picker is already open but is not the front window is it possible to make it come to front on selecting image field?
(2015-01-17, 15:36:48)davetest Wrote: [ -> ]Just installed latest commit in clean install of GS3.3.4:
I fixed the pickers, but it was late@night and Angryboy probably didn't saw them ...

(2015-01-17, 15:36:48)davetest Wrote: [ -> ]1. Image Picker for both Products and Categories does not have scrollbar.

line 65 @ /catalog/editcategory.php should be:
PHP Code:
<input class="text" name="image" value="<?php echo $cat->get('image'); ?>" placeholder="http://" id="image" onClick='window.open("../admin/filebrowser.php?CKEditorFuncNum=1&returnid=image&type=images","mywindow","width=600,height=500,scrollbars=yes")'/> 

line 95 @ /catalog/editproduct.php should be:
PHP Code:
echo '<input type="text" class="text" name="' $field['name'] . '" id="' $field['name'] . '" value="' $value '" onClick=\'window.open("../admin/filebrowser.php?CKEditorFuncNum=1&returnid=' $field['name'] . '&type=images","mywindow","width=600,height=500,scrollbars=yes")\'>'


(2015-01-17, 15:36:48)davetest Wrote: [ -> ]2. Image Picker for Categories will not select image.
with the code above it will .... the id="image" was missing

(2015-01-17, 15:36:48)davetest Wrote: [ -> ]4. If Image Picker is already open but is not the front window is it possible to make it come to front on selecting image field?
It can be done, try this code in line 65 @ /catalog/editcategory.php (instead of the above)

PHP Code:
<input class="text" name="image" id="image" value="<?php echo $cat->get('image'); ?>" placeholder="http://" onClick='window.open("../admin/filebrowser.php?CKEditorFuncNum=1&returnid=image&type=images","mywindow","width=600,height=500,scrollbars=yes").focus();mywindow.focus();'/> 

I only checked it with Firefox+Chrom+opera on windows8.1, different browsers behave differently for window.open() and focus() ... so it needs more checking (preferably on MAC+LINUX) ....
Thanks Tzvook. I popped in your code amendments and both Image Pickers working ok for me now. I also tried your alternative 'focus' mod for categories, which worked fine in Firefox Mac v35.0, so I similarly added .focus();mywindow.focus(); to the end of line 95 of editproduct.php and that worked too.

Also tested the Image Picker 'focus' mod in Opera Mac v23.0, Safari Mac v7.1.2 and Chrome Mac v38.0. Re-focus works ok on all these browsers.

Just noticed when creating a new category, the image field is auto filled with the last used image link but when making a new product the image field is blank.

Any ideas yet about the error I reported above when I tried saving Settings/Theme or Settings/Fields?
(2015-01-18, 01:14:45)davetest Wrote: [ -> ]Thanks Tzvook. I popped in your code amendments and both Image Pickers working ok for me now. I also tried your alternative 'focus' mod for categories, which worked fine in Firefox Mac v35.0, so I similarly added .focus();mywindow.focus(); to the end of line 95 of editproduct.php and that worked too.

Also tested the Image Picker 'focus' mod in Opera Mac v23.0, Safari Mac v7.1.2 and Chrome Mac v38.0. Re-focus works ok on all these browsers.

Just noticed when creating a new category, the image field is auto filled with the last used image link but when making a new product the image field is blank.

Any ideas yet about the error I reported above when I tried saving Settings/Theme or Settings/Fields?

10x for testing

I don't get those errors and not the image thing ...
(2015-01-18, 01:20:27)Tzvook Wrote: [ -> ]10x for testing

I don't get those errors and not the image thing ...

I've now also tested on a Win8.1 machine (new out of the box) and with both IE and FF. I found when creating a new category that image field was pre-filled with the last image I saved in categories over on the Mac, so the image link data must have been remembered somewhere in GS.

I also found the same save error for Settings/Theme and Settings/Fields. Again found that Settings/Settings and Settings/Cart still saving ok, so it is interesting to hear it saves ok for you.

(My server is running PHP Version 5.3.28)
Current version integrates tzvook's changes and empty slugs for transliterations. Still do not know what is causing the settings error for theme/fields.
Further to my earlier report of Save throwing an error in Settings/Theme or Settings/Fields:

[Image: GSCatalog-save-error.jpg]

I have found that if I delete the "http://" default content of the Image field 'Default' entry, that Settings/Fields then saves fine. Other content is ok, it just doesn't seem to like "http://".

Similarly, if I delete all of the content from all of the Settings/Theme sections, it saves ok too. Manually pasting back the default content (progressively, a section at a time) saves ok for the 'Header' section, but when I get to the '(Index) Categories' section it throws the error again when I try to save after pasting back in:
PHP Code:
    <h3>
        <
a href="<?php echo catalog_get_category_url($category->get('slug')); ?>"><?php echo $category->get('title'); ?></a>
    </h3> 

So I'm wondering if some of the default install content is triggering mod_sec on my server. I've not had a mod_sec problem elsewhere.

Any thoughts?
Not made changes yet, but what happens if you delete the data/other/catalog/settings folder completely and let the plugin copy the default files over again? Do you get the same issues in the Themes section?

I will remove the http:// prefix in the next commit.
(2015-02-02, 00:46:10)Angryboy Wrote: [ -> ]Not made changes yet, but what happens if you delete the data/other/catalog/settings folder completely and let the plugin copy the default files over again? Do you get the same issues in the Themes section?

I will remove the http:// prefix in the next commit.

I removed data/other/catalog/settings folder completely and let the plugin create a new one, but save error for 'theme' persisted. Tested several times. Also tried removing data/other/catalog/theme folder completely and still got problem with the new one plugin created.

If I edit data/other/catalog/theme/Innovation.xml manually (on server) to create a file with no data in the fields, thus:
PHP Code:
<?xml version="1.0"?>
<theme>
<header><![CDATA[]]></header>
<indexheader><![CDATA[]]></indexheader>
<indexcategories><![CDATA[]]></indexcategories>
<indexfooter><![CDATA[]]></indexfooter><category><![CDATA[]]></category>
<product><![CDATA[]]></product>
<searchresult><![CDATA[]]></searchresult>
<footer><![CDATA[]]></footer><css><![CDATA[]]></css></theme> 
I can then get 'theme' to save without the error.
Maybe Tzvook can update the original first post of this topic with the link to Github. It's now a bit difficult to find it in the thread.

https://github.com/lokothodida/gs-catalog

or is it https://github.com/lokothodida/gs-catalog/tree/v0.4
There is a conflict with the following plugin:

http://get-simple.info/extend/plugin/mar...arkup/744/

When enabled a bunch of code is shown on the /catalog page . Not errors but html code. When checking source of page I see:

Code:
<div class="page"><h3>Catalog</h3>
                <pre><code>


Some other issues I have with v. 0.4:

1. It is not clear to me how to show products. When I click on a category name under /catalog page I see no products if I have made products.

i18N links (which I don't use but can't dissable) link to the wrong location:
siteroot/?setlang=ru
(2015-01-22, 20:46:09)davetest Wrote: [ -> ]Further to my earlier report of Save throwing an error in Settings/Theme or Settings/Fields:

[Image: GSCatalog-save-error.jpg]

I have found that if I delete the "http://" default content of the Image field 'Default' entry, that Settings/Fields then saves fine. Other content is ok, it just doesn't seem to like "http://".

...So I'm wondering if some of the default install content is triggering mod_sec on my server. I've not had a mod_sec problem elsewhere.

I've managed to get my host to make some mod_sec exceptions for me and I now have editing and saving 'Catalog/Settings/Theme' working fine.
They haven't yet been able to do a fix for where saving "http://" in the default content threw a mod_sec error when saving 'Catalog/Settings/Fields', but that's fine as I had been able to just delete the default field content, but that doesn't matter now anyway as Angryboy removed it from the latest build.

I also posted a similar mod_sec issue when saving some code in components, here: http://get-simple.info/forums/showthread.php?tid=7087

shaun_a mentioned there that encoding the data submitted when a 'save' happens could be a way of a possible future solution for such mod_sec issues.
Hi Angryboy - is this plugin still alive? I love what you've done so far with it. But with some work it could great!
Pages: 1 2 3 4