Products 2.24.1, is it even supposed to work with CMSMS 1.12

[Guido]

I updated my CMSMS version to 1.12 in order to be able to install Products 2.24.1.

I ran into all kinds of problems. At first I saw that I needed to declare my smarty vars as global. This fixed some of my issues (especially in my detail template).

But one of the major things I couldn't work out (and made me revert back to 1.11.13) is that the $hierarchy_item var wasn't available. I tried to use it in my hierarchy template (as I did in my now back-online version 1.11.13 with Products 2.23), but no dice. I tried to 'print_r' it, this left me with an empty var.

Maybe the $hierarchy_item was declared local in the new version of the module, but I'm stumped on how to use it like this. Anyway, this made my current hierarchy templates useless and I couldn't figure out how to work around this. Looking at the $hierdata array returned the complete hierarchy, regardless of the currently viewed hierarchy.

Another thing that I couldn't figure out was how to tie the formbuilder to the products module. I use the 'module_interaction' field in formbuilder to create checkboxes that people can check when making an inquiry about a product (whether or not to include related products). In the Products summary template used for this, I use the {$FBid} as suggested. This works fine in CMSMS 1.11.13 using Products 2.23, but in CMSMS 1.12 and Products 2.24 the {$FBid} var doesn't work, making it impossible to tie related products to an e-mail sent from a formbuilder form.

I'm willing to have another go at this, but I'm wondering: is Products 2.24 not really meant for CMSMS 2.0? Can it be used in conjunction with formbuilder (or does formbuilder need an update in order to achieve this)?

CMSMS version (working one):
----------------------------------------------

Cms Version: 1.11.13

Installed Modules:

CMSMailer: 5.2.2
FileManager: 1.4.5
MenuManager: 1.8.6
ModuleManager: 1.5.8
News: 2.15
Search: 1.7.12
ListIt2: 1.4.1
ListIt2XDefs: 1.2
ListIt2Diensten: 1.4.1
CGExtensions: 1.47.3
JQueryTools: 1.3.5.1
CGSimpleSmarty: 1.8
CGBlog: 1.12.10
AceEditor: 1.0
CGSmartImage: 1.18
CompanyDirectory: 1.22.9
CustomGS: 2.1
ECB: 1.6
GBFilePicker: 1.3.3
Products: 2.23
TinyMCE: 2.9.12
ListIt2Occasions: 1.4.1
NeoModule: 0.5.5
FormBuilder: 0.8.1.1
HitCounter: 2.0


Config Information:

php_memory_limit: 64M
process_whole_template:
max_upload_size: 10000000
url_rewriting: mod_rewrite
page_extension: .html
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale: nl_NL
default_encoding: utf-8
admin_encoding: utf-8
set_names: true


Php Information:

phpversion: 5.5.25
md5_function: Aan (Waar)
gd_version: 2
tempnam_function: Aan (Waar)
magic_quotes_runtime: Uit (Onwaar)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 64M
max_execution_time: 259200
output_buffering: 4096
safe_mode: Uit (Onwaar)
file_uploads: Aan (Waar)
post_max_size: 64M
upload_max_filesize: 10M
session_save_path: Geen controle omdat 'open_basedir' actief is
session_use_cookies: Aan (Waar)
xml_function: Aan (Waar)
xmlreader_class: Aan (Waar)


Server Information:

Server Api: apache2handler
Server Db Type: MySQL (mysqli)
Server Db Version: 5.5.31
Server Db Grants: Er is een "GRAND ALL" permissie gevonden, alles lijkt in orde.
Server Time Diff: Geen tijdverschil aangetroffen


----------------------------------------------

[calguy1000]

The products module works just fine with 2.0.
The difference is, in all of my modules now. To solve problems with variables overwriting each other (particularly encountered when calling one module or plugin or from within another module's templates) I am now taking advantage of the new smarty scoping mechanism.

That means if you want to use a variable created from within the module, in another location you must explicitly share it.

To share a variable you simply add the scope=global attribute to an assignment.
i.e:

Code: Select all

{assign var='foo' value='bar' scope=global} 

or it's short form

Code: Select all

{$foo='bar' scope=global}

Here's a shortcut to take an existing variable and create a global variable with the same from it.

Code: Select all

{$foo=$foo scope=global}

As far as Formbuilder goes, I suspect it's a similar problem. but I have never used formbuilder in this way.

[Guido]

Hey Callguy,

Thanks for your reply. I had read your post about the smarty scope and was able to solve a lot of bumps using this.

I was just now playing around with some caching and noticed something: in my 'old' setup (that I currently use, so CMSMS 1.11.13 and products 2.23), when I turn on smarty caching I get the exact same weird behaviour as I got with CMSMS 1.12 and products 2.24. Could it be that upgrading to CMSMS 1.12 from 1.11.13 (I used the DIFF package) set smarty caching to true? I didn't check this while testing CMSMS 1.12 / products 2.24.

The reason I was questioning the smarty scope was because I had no access to the hierarchy_item array in my hierarchy template (though even the factory sample template uses this array). I though maybe the module registers the array as local, but maybe the smarty caching is something I overlooked.

[calguy1000]

The upgrade did not enable smarty caching.... it never has. smarty caching is a similar but different animal.

smarty caching generates HTML files for each of the cachable templates, and uses them for an hour or until the templates. so if caching is enabled the cachable template only gets executed once... and therefore smarty variables created inside that template will not exist for other templates after the first run.

[Guido]

Okay thanks for this explanation. So to recap (just for my understanding): If I enable smarty caching and call my hierarchy page for 'cars', the page template is called and the hierarchy template for 'cars' is saved as a static HTML file. Any subsequent call for that page template in the first hour after that will just paste the previously mentioned static HTML file for 'cars' in place of the {Products} call, in stead of actually performing a database request for the correct hierarchy (assuming that a different hierarchy then 'cars' is requested).

Also, in this case the $hierarchy_item variable would not be created by the PHP call to the database at this point, because there was no PHP call to the database (or at least not to retrieve the current hierarchy info). This would certainly explain the absense of certain variables I experienced, so maybe I need to re-test this and make sure all caching is turned off at the first testing stage.

Do the paragraphs above make sense? Or am I on the wrong track here?

Subsequently: What happens when you set a page to 'cacheable'? Does smarty also create a static HTML file for the entire page? I tried this for my products detail page, and added {nocache}{/nocache} blocks around certain {Products} calls (I save the last viewed product in the session via cge_session_put and retrieve it on following detail pages), but I had some issues with this. Does the {nocache} option block smarty caching and/or page caching, or are they basically the same thing?

=========== EDIT ==========
As I was looking around in the smarty template cache files, I saw what you mean. I found a cache file for the hierarchy template I had problems with. At the start of it (before the actual template content), I found an array that set general variables:

Code: Select all

  array (
    'hierarchy_item' => 0,
    'tmp' => 0,
    'ouders' => 0,
    'ouder' => 0,
    'huidigeouder' => 0,
    'hierdata' => 0,
    'active_hierarchy' => 0,
    'item' => 0,
    'class' => 0,
  )

Basically telling me that the '$hierarchy_item' var I was looking for is empty when cached content is used.

[calguy1000]

Okay thanks for this explanation. So to recap (just for my understanding): If I enable smarty caching and call my hierarchy page for 'cars', the page template is called and the hierarchy template for 'cars' is saved as a static HTML file. Any subsequent call for that page template in the first hour after that will just paste the previously mentioned static HTML file for 'cars' in place of the {Products} call, in stead of actually performing a database request for the correct hierarchy (assuming that a different hierarchy then 'cars' is requested).

That is essentially it... though it is a little bit smarter, depending on nocache sections, and the parameters passed to the module(s).

Also, in this case the $hierarchy_item variable would not be created by the PHP call to the database at this point, because there was no PHP call to the database (or at least not to retrieve the current hierarchy info).

Correct

Subsequently: What happens when you set a page to 'cacheable'? Does smarty also create a static HTML file for the entire page?

Well, smarty is 'smart'. it caches only the portions that can be cached according to a number of rules, (including cachable plugins, non-cachable plugins, nocache sections, etc). Though I haven't tested explicitly for this, if the entire page was cachable (i.e: none of the plugins or sections called on that page were deemed non-cachable) then I would guess that entire page would be cached.

However, this cachable behaviour is similar to, but not identical to the behaviour of the new variable scope issue.

The new variable scope stuff behaves similarly to the way PHP normally works.
i.e: imagine this simple php code:

Code: Select all

$items = null;
function output_list() {
   // this $items is in a different scope than the one outside this function
   $items = array('item1','item2','item3');
   echo '<ul>';
   foreach($items as $item) echo "<li>$item</li>";
   echo '</ul>';
}
output_list();
print_r($items);   // this will output nothing

.

Because the function creates a new variable scope, the items created inside the function are lost and cannot be used ouside of it.

WRT smarty template scopes, the behavior is similar. Even though your template is called, and the variables are created locally, they are destroyed when that template goes out of scope, unless you explicitly copy them to another scope.

[Guido]

That is essentially it... though it is a little bit smarter, depending on nocache sections, and the parameters passed to the module(s).

I saw this in the cache files. The cache file stores some variables the module may need.

However, this cachable behaviour is similar to, but not identical to the behaviour of the new variable scope issue.

I'm afraid I don't follow you all the way here. Do you mean the cached files also have a 'scope'? I'm taking an online PHP course where I learned about the scopes within functions (and how variables are not available outside these functions unless you explicitly make them available) so I could follow your example but I'm not really sure on how to apply this filosophy on caching.

As from your example, the function 'output_list()' will output the list items from within the function (because the items exist in the function), and calling the items directly will output nothing because there are no items outside of the function, right?

[Guido]

Here's an offtopic thought:

I know you are looking for people working on documentation files. Since I am originally a journalist and have written several technical manuals, I could write (dutch and english) documentation from the viewpoint of a relatively unexperienced developer (which I am). The dev team could verify my texts on a technical level to make sure the technical details are correct. This way the threshold for new adopters would be low.

Let me know if you would be interested in this.