template_func.php not working with custom product type

There is only a small change in the new includes/classes/template_func.php file in 1.3.5, but it seems to be breaking display of my custom product type, document_register, which is pretty much identical to document_product, I haven't done anything special with it (yet.)

The new template_func.php causes this error to appear in product display:

Warning: preg_match(): Unknown modifier 't' in /home/corek2/public_html/book135/includes/classes/template_func.php on line 60

Example: (but this will probably not show, I can't afford to leave it hanging around in live bookstore)
document_register product type info display example

Restoring the old template_func.php solves the problem.

There are only these differences in old/new:

lines 57-60 1.3.0 version:

    if ($mydir = @dir($file_dir)) {
      while ($file = $mydir->read()) {
        if ( strstr($file, $file_pattern) ) {

lines 57-60 1.3.5 version:

    $file_pattern = '/'.$file_pattern.'$/';
    if ($mydir = @dir($file_dir)) {
      while ($file = $mydir->read()) {
        if (preg_match($file_pattern, $file)) {

preg_match function is found in includes/functions/functions_email.php and in admin/includes/functions/localization.php, and I think it is unchanged since version 1.3.0.

I don't know if this is a genuine bug, or if there's something wrong with my custom template, which has been working fine in all other respects.

I have not made any modifications to functions.

Apologies if this issue is not a bug after all!

---Diana

By the way, the /book135/ installation directory does not exist any more, so the links above will not work. It was my parallel update site and is now my regular bookstore site.

I have completed my upgrade to 1.3.5!!!

---Diana

so ... you're saying there's not a problem anymore?

thanks for reply, wonderful Dr. Byte!

There's no problem ONLY IF I use the 1.3.0 version of template_func.php.

I have the other one ready to load in an instant if you want to see it, but I prefer not to leave it up there, heh.

Hmm, I'm not sure if this is affecting my sandbox site, I will check if it can be used to demonstrate the problem.

---Diana

Hmm... the new template_func.php is working fine on my test site, also upgraded to 1.3.5, and it has the same custom document type. That doc type is used for the "registration" items, and for the online preschool assessment tool.

So... I need to better understand the error message to make any headway.

I see that preg_match is commented out of functions_email.php, so that is irrelevant. So this must come from admin/includes/functions/localization.php ... but this seems to be about currency handling. I thought that template_func.php has to do with file names. Is there another instance of preg_match?

I don't know how/where preg_match would be passed a modifier "t".

Note that my test site is a cobbled-up update, files overwritten, and more liable to errors.

The main bookstore site (see sig) is a clean 1.3.5 install, with all modifications and customizations carefully added.

---Diana

Someone just registered on the test site as "sdf".

Are you testing?

I don't want to authorize you unless you are testing, you can send me a PM.

---Diana

by the way, I did find some discrepencies with admin\includes\modules\document_register\collect_info.php and preview_info.php files, and the admin display_info file for this custom mod, which had not been fully updated to the new versions, but after updating this doesn't seem to have had any impact on the reported problem.

d'oh...

preg_match is a built-in PHP function.

This is probably not a bug, probably a mysterious misconfiguration somewhere... so, this topic (er, rumination) can probably be moved to, um, custom product types?

---Diana

The only other thing I have to suggest is that in my new Bookstore, I have in my .htaccess file (per ZC recommendations):

php_value register_globals off
#php_value register_globals off
<Files ".ht*">
deny from all
</Files>

I don't have register_globals off in the test store... I'll give that a try and see if that reproduces the problem.

Woohoo, that was it!

I added these lines to the .htaccess file and bammo.

php_value register_globals off
#php_value register_globals off
<Files ".ht*">
deny from all
</Files>

You can see it happening here now.

OK, why does having register_globals off cause this?

Let me know if you need my version of PHP or any other server stuff.

---Diana

edit: oooh... it could be... I used a reserved PHP word in my custom document type!!!! "document_register"
Do you think that's it, Dr. Byte?

not sure why the register_globals should have any effect.

The correct fix is to edit template_func.php

and replace the line (57)

from

$file_pattern = '/'.$file_pattern.'$/';

to

$file_pattern = '/'.str_replace("/", "\/", $file_pattern).'$/';

the problem was caused, by a directory separator in the file pattern, which is only ever there if the file pattern represents a custom template page override.

Splendid!

Thanks so much, Wilt. Works like a charm. I wonder if this affects other ZC'ers?

---Diana

...did I ever say how great you ZC devs are? you are!!

wilt:

not sure why the register_globals should have any effect.

The correct fix is to edit template_func.php

and replace the line (57)

from

$file_pattern = '/'.$file_pattern.'$/';

to

$file_pattern = '/'.str_replace("/", "\/", $file_pattern).'$/';

the problem was caused, by a directory separator in the file pattern, which is only ever there if the file pattern represents a custom template page override.

I hope you will concider this...

I tend to disagree with this fix. There are many places in the code that call get_template_dir with the foreslash, like this in tpl_products_all_default.php:

require($template->get_template_dir('/tpl_modules_products_all_listing.php',DIR_WS_TEMPLATE, $current_page_base,'templates'). '/tpl_modules_products_all_listing.php'); ?>

but there are places like this too that call it without the leading foreslash:

<?php require($template->get_template_dir('tpl_modules_also_purchased_products.php', DIR_WS_TEMPLATE, $current_page_base,'templates'). '/' . 'tpl_modules_also_purchased_products.php');?>

lets say that DIR_WS_TEMPLATE is 'nnw' and $current_page_base is 'index'
To me, what line says is "first look in the 'nnw/index' dir for '/tpl_modules_products_all_listing.php' and if you don't find it try other places...

Well it will never find '/tpl_modules_products_all_listing.php' because as you correctly assumed, there was something wrong with line 57. it made the regx pattern, //tpl_modules_products_all_listing.php/. The error that gave was that 't' is not a known modifier. and that is right. the search pattern was looking for a null modified with 't' (//tp...).

Here is my objection. simply replacing the leading slash with an escaped one is not what you want to do. that will give you this pattern:
//tpl_modules_products_all_listing.php/
That means you will be searching a directory for anything that matches a filename with a leading foreslash, and that cannot happen, filenames just don't have leading foreslashes.

Thus, no file will ever be found on line 46, and no matter what you have in 'nnw/index' it will not be used and one of the other locations will be used instead, but never the first choice.

What should really be done is to make sure that none of the calls to get_template_dir have filename patterns that begin with '/'.

Barring that, they should be stripped off right after the routine begins.
or alternately change line 46 from this:

    if ($this->file_exists($current_template . $current_page, $template_code)) {

to this:

    if ($this->file_exists($current_template . $current_page, ereg_replace('/', '', $template_code))) {

like the other calls to file_exists() do.

Best Regards,
Bill Wheaton
Nease's Needlework
http://neasesneedlework.com
Decatur, GA