Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Is there a limit to the number of Global declarations?


ArtcoInc

Recommended Posts

phoenix 1.0.1.4

I am taking a shopping cart module (the Ship in Cart 5.0 CE Phoenix add-on), and adding a condition that it will only display if there is sufficient stock on hand for all items in the cart. I have successfully done this to several other shopping cart modules. What I do is add the $any_out_of_stock variable to the Global declaration in the module, and add an IF clause in the template.

Like I said, I have done this to several other shopping cart modules (the checkout button, the order total module, etc) without any problems. But, when I add the $any_out_of_stock variable to the Global declaration in this module, the Admin -> Modules -> Content page looses its format! This is the only change I have make to this module.

There are already 22 declarations in the module:

Quote

      global $oscTemplate, $currencies, $currency, $request_type, $cart, $order, $total_count, $quotes, $method, $module, $shipping, $navigation, $cart_sid, $cart_country_id, $cart_zone, $cart_zip_code, $cart_address_id, $total_weight, $language, $customer_id, $sendto, $billto;

I've tried adding the $any_out_of_stock at the beginning. I've tried adding it at the end. Same results.

So, is there a limit to the number of Global declarations? A size limit? Or, is there something else that, by just adding this declaration to this module, could cause the Admin screen to loose it's format?

TIA

Malcolm

Link to comment
Share on other sites

I never observed that something breaks due to too many global variables use. But easy way to check: replace one of the variables already listed instead to add another one. If it breaks it’s not the number of variables but something else.

Link to comment
Share on other sites

@raiwa

Since this was only a test, I just replace the $quotes declaration with $any_out_of_stock, and the loss of format still happens. I reverted back to a clean copy of the file, and the format changed back to what it was supposed to be.

Thinking that the length of the list of declarations may be a factor (since $quotes is shorter than $any_out_of_stock), I replaced both the $currencies and $currency declarations with $any_out_of_stock (since the length of those two combined was longer than the length of $any_out_of_stock), and the loss of formatting still happened. Again, reverting back to a clean copy of the original file, the formatting changed back to what it was supposed to be.

So, it doesn't seem to be either the number of declarations, nor the length of the names. I am at a loss. I have added this variable to the Global definitions in other modules without this problem.

Any thoughts?

Malcolm

Link to comment
Share on other sites

@burt @raiwa

Just so everyone can see the issue I'm having, here's a screen shot with the formatting the way it is supposed to be:

705336872_ScreenCapture2019-09-19-A.jpg.e488e85789fbd854750b71668ca194aa.jpg

 

And here's the same page, same resolution, after adding the Global variable to the module:

2112231831_ScreenCapture2019-09-19-B.jpg.cda62e759c799ec7c7ea60029158baab.jpg

 

You can see how the screen format has changed. Note, this formatting change ONLY happens in the admin/modules_content.php page.

Why was the formatting in Admin -> Modules -> Content changing? To see if the actual generated HTML code was different, I displayed the Admin screen, and did a View Source. I copied the generated HTML code to a file.

I then edited the module, and redisplayed the Admin screen. The formatting was again messed up. I did a View Source, and copied the generated HTML code to another file.

I then used WinMerge to compare the two files. They were the same!

I went through the exercise again, this time, using Inspect Element in Firefox, I used the Style Editor to capturing the resulting CSS. Again, both before and after were the same!

So, this leads me to believe that there is something in admin/modules_content.php that is messing up, although I have NO IDEA of what that could be ...

I'm open to ideas ...

TIA

Malcolm

Link to comment
Share on other sites

Switch error reporting on, this layout change can be due to php errors.

Link to comment
Share on other sites

@burt

The module is in the correct /includes/modules/content/shopping_cart directory, and the template is in the correct /includes/modules/content/shopping_cart/templates directory. The formatting problem is in /admin/modules_content.php, and as far as I can tell,  is caused just by adding the one additional Global definition to the module code. Adding it, the formatting in Admin has problems. Removing it, the formatting goes back to normal.

I considered that, since I was testing for the additional Global definition in the template, it might be the template that was causing the problem. Reverting back to the stock template did not resolve the problem.

The thing is, when I add the Global definition, and test for it in the template, I get the results I want (that particular module will or will not display if there is or isn't sufficient stock on hand). So, in that respect, on the Shop side, it all works. And, I use this same conditional test in other modules in the Shopping Cart, and they also work on the Shop side, but do not have the formatting issues in Admin. The only issue is the screen formatting in Admin with this one module.

As I said, I have examined both the generated HTML code and the CSS code for the Admin page when the formatting is correct, and when it isn't. The code is the same both ways. So I don't see why one displays correctly, and one doesn't.

It could just be a quirk in the setup on my in-house WAMP development server. I tested accessing the Admin side of the server from another workstation on the LAN, using two different browsers, and got the same results. I suppose I *could* just live with it, but ...

Link to comment
Share on other sites

Have had this problem on one site also, never got to the bottom of it. Only on content module styling is odd and oversized, rest of admin workes fine. Not found any stray files or anything else that may cause it. I added styling overides to fix it but that's just putting a plaster over the actual cause is still not known. It may just be that config got messed up on install or it's pulling styling from another content file?

 

image.thumb.png.219b53937bfbb753c7ec2e3ae96a762a.png

 

Link to comment
Share on other sites

I suppose I should take some comfort in knowing that I am not the only one who has had this problem ... but I won't.

It does point out that there is an issue in /admin/modules_content.php in that, under certain conditions, the screen formatting will fail. And, this problem is repeatable and reproducible. I have looked at the code, but it's too much for this old mind to wrap around, and investigating this would take time away from getting my shop finished.

M

Link to comment
Share on other sites

So did some further investigation on this problem on a test site as it was proving imposable to debug. I would NOT recommend anyone doing this on a live site as it will brake your site! You have been warned.

So as this only affected the contents section of admin, to try and narrow down the cause I eliminated parts of the includes/modules/content one at a time. I did this by renaming the folders one at a time and checking the effect on admin.

Staring from the bottom nothing had any effect until I got to header! Once this was renamed the problem with the content in admin was no longer an issue it looked like any other section. So one my site it was clear the problem was confined to the header folder. Wonderful so now I could look into this and find what was causing the problem.

Well no! In renaming the folders to find the cause of the problem what I did not spot was that each time I renamed a folder all the modules in that folder were being removed from the configuration file!! So they were effectively being uninstalled automaticity.

So first I had to reinstall all the modules to get the site back to original status. lesson learned, never rename a module folder!!

However having restored the modules and taken time to look into the header folder content I was unable to find anything wrong with any of the files. Turning off and removing each module one at a time did not fix the problem. It would only work if you removed the header folder totally.

 So stll not clear what the cause is/ was! The fix I used to fix the issue was to add a small css fix to the admin style sheet.

.smallText {
font-size:0.7rem;}


 


 


 

 

Link to comment
Share on other sites

I had something different early today. The format of the admin order page grows bigger and bigger without stopping.😰 

Then I realized I have not removed a particular add-on cleanly. There was a <body onload=go()> in the template_top.php. The page returned to normal only after I removed the embedded function.

 

Possibly some js is messing things up.

Link to comment
Share on other sites

Hi @ArtcoInc

I was looking and found the reason why I had that problem.

The problem arose from some <style> ... </style> within a template file.

I don't remember well if I finish it with </ style> instead of </style> .... (a space within / and style)

In summary look at the changes you made recently to your template files and look at the style code to see if it is well written.

I wish you luck.

Valqui

:heart: Community Oscommerce fan :heart: You'll find the latest osC community version here.

 

Link to comment
Share on other sites

  • 9 months later...

*** UPDATE ***   (this is going to be a long one)

Ok, I moved on to work on other things. When this came back into my attention, I decided to attack this again with new eyes.

First, I opened 'view source code' in my browser for this page (admin/modules_content.php). 

1724722110_ScreenCapture2020-07-17-A.jpg.eb3b87c4d11114e8d101bd7d5fd7e3dd.jpg

Notice the circled areas. The red indicates something that the browser had to add to get the page to display right (or, something like that)

I also opened 'view source code' for /admin/modules.php, and compared the generated results.

1873805221_ScreenCapture2020-07-17-B.jpg.42bdfa3c84f25774ad69320b016f0173.jpg

For *some* reason, /admin/modules_content.php was not pulling in /includes/template_top.php correctly. It was messing up the <head></head> information, pushing it down into the <body> section.

I verified this using the Inspect Element tool. This is the generated code from admin/modules_content.php. Note the missing DOCTYPE line, and that there is nothing between <head> and </head>. Also note that the beginning of the <body> includes the code that is supposed to be in the <head> area ...

1615654275_ScreenCapture2020-07-17-C.jpg.b44a20f7c7ffb3de2fe984dbf826b0cc.jpg

 

For comparison, this is the results from using the Inspect Element on admin/modules.php ...

1237233204_ScreenCapture2020-07-17-D.jpg.1fc7d47db1f4929abefc3020cc1c2879.jpg

Note that the DOCTYPE is there, that there is stuff in the <head> </head> , and that the <body> contains just the proper HTML code.

(also for comparison, I've expanded the <head> </head> below)

577337555_ScreenCapture2020-07-17-E.jpg.cb42a61f1347ba337b52ac7899cc85d8.jpg

 

Ok, so I though that since template_top.php wasn't being loaded properly, what would happen if I moved the require('includes/template_top.php'); line up to just under the  require('includes/application_top.php');  line?

It worked! The admin/modules_content.php loaded correctly! Problem solved!

Actually, no, it didn't. While it fixed the problem loading template_top.php, resulting in better generated HTML code, and the screen displayed as it should, if I actually tried to edit any of the modules, everything crashed ...

1395555341_ScreenCapture2020-07-17.jpg.87ad9be159326e4b9e0a8897faae44fe.jpg

I've tried moving the require('included/template_top.php"); line up and down, but unless it is just before where the HTML code starts, it always crashed when trying to add/edit/delete a module. So, I had to put it back where it was originally.

Which leaves me back at where I started from.

This all started when edited the Shopping Cart module to include one additional Global declaration. I still don't know how this has caused admin/modules_content.php to mess up the way it is. I can see HOW it is messing up, but I have no clue as to why, or how to resolve it.

Any thoughts or clues?

TIA

Malcolm

Link to comment
Share on other sites

In your module, leave off the global $any_out_of_stock and replace all occurrences of $any_out_of_stock with $GLOBALS['any_out_of_stock']

If that doesn't help, please post every line where you use any_out_of_stock. 

The reason why it doesn't allow you to add/edit/delete is that all of those do redirects.  You can't emit any HTML until after you do redirects. 

It's acting like something is causing it to emit output early -- see if you can figure out what is doing that.  It would probably be something gated by any_out_of_stock. 

Always back up before making changes.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...