Jump to content

List of pages by template timing out


creativejay
 Share

Recommended Posts

2017-10-16 13:47:40	guest	http://comnet.net/comnet-products/ethernet/media-converters/cnfe2mcpoe.html	Error: 	Uncaught Error: Call to a member function getConfigData() on null in /wire/core/Pageimage.php:486 Stack trace: #0 /public_html/wire/core/Pageimage.php(346): ProcessWire\Pageimage->___size(300, 0, Array) #1 /public_html/site/assets/cache/FileCompiler/site/templates/product-display-superlongform.inc(25): ProcessWire\Pageimage->size(300, 0, Array) #2 /public_html/site/assets/cache/FileCompiler/site/templates/prod_series.php(2): include('/...') #3 /public_html/wire/core/TemplateFile.php(268): require('/...') #4 /public_html/wire/core/Wire.php(380): ProcessWire\TemplateFile->___render() #5 /public_html/wire/core/WireHooks.php(698): ProcessWire\Wire->_callMethod('___render', Array) #6 /public_html/wire/core/Wire.php(442): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array) #7 /public_html/wire/modules/PageRender.module(51 (line 486 of /public_html/wire/core/Pageimage.php)
2017-10-16 13:51:08	guest	http://comnet.net/about/news	Error: 	Uncaught Error: Call to undefined function imagecreatefromstring() in /public_html/site/assets/cache/FileCompiler/site/modules/PageImageManipulator/ImageManipulator02.class.php:812 Stack trace: #0 /public_html/site/assets/cache/FileCompiler/site/modules/PageImageManipulator/ImageManipulator02.class.php(1968): ImageManipulator02->imLoad() #1 /public_html/site/assets/cache/FileCompiler/site/templates/news.php(69): ImageManipulator02->canvas(50, 50, Array, 'n', 0) #2 /public_html/wire/core/TemplateFile.php(268): require('/...') #3 /public_html/wire/core/Wire.php(380): ProcessWire\TemplateFile->___render() #4 /public_html/wire/core/WireHooks.php(698): ProcessWire\Wire->_callMethod('___render', Array) #5 /public_html/wire/core/Wire.php(442): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array) #6 /public_html/wire/modules/PageRender.module(514): ProcessWire\Wir (line 812 of /public_html/site/assets/cache/FileCompiler/site/modules/PageImageManipulator/ImageManipulator02.class.php)
2017-10-16 13:54:34	guest	http://comnet.net/comnet-products/ethernet/media-converters/cnfe1m1ms-x.html	Error: 	Uncaught Error: Call to a member function getConfigData() on null in /public_html/wire/core/Pageimage.php:486 Stack trace: #0 /public_html/wire/core/Pageimage.php(346): ProcessWire\Pageimage->___size(600, 0, Array) #1 /public_html/site/assets/cache/FileCompiler/site/templates/product-display-superlongform.inc(180): ProcessWire\Pageimage->size(600, 0, Array) #2 /public_html/site/assets/cache/FileCompiler/site/templates/prod_series.php(2): include('/...') #3 /public_html/wire/core/TemplateFile.php(268): require('/...') #4 /public_html/wire/core/Wire.php(380): ProcessWire\TemplateFile->___render() #5 /public_html/wire/core/WireHooks.php(698): ProcessWire\Wire->_callMethod('___render', Array) #6 /public_html/wire/core/Wire.php(442): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array) #7 /public_html/wire/modules/PageRender.module(5 (line 486 of /public_html/wire/core/Pageimage.php)
2017-10-16 13:55:08	(superuser in admin)	Error: 	Allowed memory size of 33554432 bytes exhausted (tried to allocate 1126400 bytes) (line 191 of /public_html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-master/src/Tracy/BlueScreen.php)

These are my error logs from debug. I stripped out the /root/user portion of the paths reported.

Link to comment
Share on other sites

I tried clearing my cache files and it got worse.

From the front end:

Error: Uncaught Error: Call to undefined function _() in /public_html/site/modules/ListSiblingsTab/ListSiblingsTab.module:12

And in the backend:


 3:    /**
 4:     * Add "Siblings" tab to page editor.
 5:     *
 6:     */
 7:    
 8:    class ListSiblingsTab extends \ProcessWire\WireData implements \ProcessWire\Module {
 9:        public static function getModuleInfo() {
10:            return array(
11:                "title"        =>    "Page Edit Siblings",
12:                "summary"    =>    _("Add siblings tab to page edtior"), // <--- This line 
13:                "version"    =>    "0.0.1",
14:                "autoload"    =>    true
15:            );
16:        }

 

Link to comment
Share on other sites

$this->_() corrected it in the front end. For a minute.

Then I went looking for more errors in the admin, and after accessing the , I see

Quote

Deprecated

call_user_func() expects parameter 1 to be a valid callback, non-static method ListSiblingsTab::getModuleInfo() should not be called statically

And, as a bonus:

File: /public_html/wire/core/Modules.php:2360
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 266240 bytes) in /public_html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-master/src/Tracy/BlueScreen.php on line 217

Error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 266240 bytes) (line 217 of /public_html/site/modules/TracyDebugger/tracy-master/src/Tracy/BlueScreen.php)

This error message was shown because: site is in debug mode. ($config->debug = true; => /site/config.php). Error has been logged.

I cleared my cache and sessions directory.

I am running the latest stable PWire install.

So I manually shut down the Siblings editor module and gained access to the back end again.

Searching for more errors, now.

Found some:

That memory size message.

Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 21119000 bytes) (line 812 of /site/modules/PageImageManipulator/ImageManipulator02.class.php) 

 

Edited by creativejay
Found another error
Link to comment
Share on other sites

5 minutes ago, szabesz said:

Regarding "33554432 bytes exhausted": 32MB is not too much. Since you are on VPS, you should be able to enable more for your site.

It usually happens to me when there are a lot of errors, or when there's an endless recursion in my code

  • Like 2
Link to comment
Share on other sites

1 minute ago, creativejay said:

Now getting (silently failing) errors with FormBuilder (latest ver):

Call to undefined function __()

referring to this line:


<html lang="<?php echo __('en', __FILE__); // HTML tag lang attribute

 

Filecompiler should have taken care of that

Add namespace to the first line: <?php namespace ProcessWire;

  • Like 2
Link to comment
Share on other sites

Okay!

Hosting went through each module for PHP 5.6 and installed/enabled the 7.0 equivalent.

They also increased the allowed_memory size to 512M when they experienced the same issues.

I'm going to have to work on the news section. I don't know if it's Pagination or my code, but that's eating up resources like Halloween candy.

 

Okay.. that storm past, I will hold my breath and start the PHP-FPM.

Link to comment
Share on other sites

Thanks! I'm hands-off for the moment so I don't lose anything in the account switch to allow for PHP-FPM. Then I'll take a peek at that module.

You guys have saved me hundreds of hours of beating my head against my desk, and probably added a few years back to my life by alleviating stress.

I can't thank you enough. With the update to PHP 7 the server is already running far faster. I was able to put back in those feat_icon_imgs that I yanked out yesterday, even!

Now it's just a wait to see if there's fallout from the next step, and then I'm in the home stretch!

  • Like 2
Link to comment
Share on other sites

9 hours ago, creativejay said:

That it's returning 245 results

I'm confused by this - didn't you say that the maximum number of products you are currently listing is 37? 245 pages is more pages than you want to be loading without a limit. If you are later filtering these 245 pages down to 37 or whatever you should try and rework it so you are getting only the 37 in the initial $pages->find(). 

  • Like 2
Link to comment
Share on other sites

11 hours ago, Robin S said:

I'm confused by this - didn't you say that the maximum number of products you are currently listing is 37? 245 pages is more pages than you want to be loading without a limit. If you are later filtering these 245 pages down to 37 or whatever you should try and rework it so you are getting only the 37 in the initial $pages->find(). 

There are 245 potential matches for any product search, but right now my largest display on any pages, the way they're called, is 37. I *do* want to offer a complete list in two spots on the site,  but that didn't seem wise with the lag we were experiencing. 

The site has sped up considerably since my host upgraded the PHP, and PHP-FPM seems to have also been a speed boost. I'm going to be more careful with my find()s, but I'm going to be looking at how best to add those two find()s resulting in 245 back in. One can have pagination (though the pages with pagination seem to be where I got those memory errors, though I haven't investigated more at this point), but the other should be a very basic list of the pages with links to the files they contain, and the point of that page has always been a quick reference without having to click through multiple pages. But maybe I'll add a search bar to that page instead if it still loads slowly.

Link to comment
Share on other sites

7 minutes ago, creativejay said:

There are 245 potential matches for any product search

Meaning you have this number of published, non-hidden products, right? A simple "template=my_products" selector should be fast enough and by storing the result in memory (eg. assigning it to a variable) can give you the possibility to work with it afterwards. With 512MB RAM it should not be an issue, I guess.

  • Like 1
Link to comment
Share on other sites

Yes, roughly. There is also a Page reference (single value) field that defines the product per our company's stages of production (preliminary, new release, worldwide, NA only, EMEA only, and obsoleted). So the 255 is further refined by the page id values of those fields. But I still wouldn't expect it to be a serious draw on resources to double check those. But if you think it would save PWire brainjuice, I could switch to a standard Options field, instead.

 

The call is:

///in my header.inc...
$productCatList="prod_series|prod_series_ethernet|prod_series_access|prod_series_accessories|prod_series_fiber|prod_series_pwr_supplies|prod_series_pwr_systems|prod_series_wireless";
$getCurrentProdOptions="template=$productCatList, prod_status_pages!=1554|1559|1560|4242";
// and then wherever I need it...
$products = $pages->find("$getCurrentProdOptions"); 

 

Link to comment
Share on other sites

Just now, szabesz said:

Should not matter too much as far as I know.

That's what I figured. It's faster than it was before the Apache/PHP upgrades but it's still long enough that I get a script warning from jquery on the page for the first run.  The page loads like a dream with ProCache. I just want to improve it for the poor sucker that hits it for the first time each expire. (or is there a 'never expire' setting in ProCache I've missed that will allow me to reload it manually and be that sucker, myself?)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...