Jump to content
creativejay

List of pages by template timing out

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.

Share this post


Link to post
Share on other sites

Rename site/assets/cache/FileCompiler folder to .FileCompiler or something else to force compile templates & modules. Flush Procache cache.

Also, which version of PW are you on?

Share this post


Link to post
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:        }

 

Share this post


Link to post
Share on other sites

Try removing static keyword from method signature, or change _() to __() or $this->_() or prepend _() with backslash \_().

  • Like 2

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Refresh your modules cache using $modules->refresh() in init.php/ready.php (or any template really) or Modules > Refresh from the admin

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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"); 

 

Share this post


Link to post
Share on other sites

As the site propagates across the world's servers, the first question I get is "where's that page with all the downloadable files for each product?" This was, of course, the slow page that began this whole thread. :P

Share this post


Link to post
Share on other sites
1 hour ago, creativejay said:

But if you think it would save PWire brainjuice, I could switch to a standard Options field, instead.

Should not matter too much as far as I know.

Share this post


Link to post
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?)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By jds43
      Hello,
      Does anyone have experience with migrating content from Django to Processwire? Or are there any suggestions for achieving this?
    • By DooM
      Hello guys,
      I'm trying to figure out how to sync fields and templates between staging and production environments.
      I've found Migrations module by Lostkobrakai, but with use of it all the fields and templates must be created by API, which is kind of uncomfortable.
      I also tried ProcessDatabaseBackups module which can export only certain tables, but I don't think it's the best practice to do that.
      How do you guys solve this problem? It's very annoying to setup everything three times (dev, staging, production).
      Thanks a lot :)
    • By Brawlz
      Hi,
      I hope this is the correct section for my problem.
      All I need is a connection to an external Database and a query gettings some data. I do this in a processwire Page-Template. I am honestly not sure if it is a problem with processwire or my code:
      $host = ‚XXXXX’; $user = ‚XXXXX‘; $pass = ‚XXXXX‘; $db = ‚XXXXX‘; $port = ‚3306‘; $mydb = new Database($host, $user, $pass, $db , $port);  $result = $mydb->query("SELECT * FROM char“);  while($row = $result->fetch_assoc()) {  print_r($row);  }  
      Produces the following error:
      Error: Exception: DB connect error 2002 - Connection timed out (in /customers/9/4/e/XXXX.de/httpd.www/wire/core/Database.php line 79)
       
      I also tried connecting without the $port variable but got the same error.
    • By Mobiletrooper
      Hey Ryan, hey friends,
      we, Mobile Trooper a digital agency based in Germany, use ProcessWire for an Enterprise-grade Intranet publishing portal which is under heavy development for over 3 years now. Over the years not only the user base grew but also the platform in general. We introduced lots and lots of features thanks to ProcessWire's absurd flexibility. We came along many CMS (or CMFs for that matter) that don't even come close to ProcessWire. Closest we came across was Locomotive (Rails-based) and Pimcore (PHP based).
      So this is not your typical ProcessWire installation in terms of size.
      Currently we count:
      140 Templates (Some have 1 page, some have >6000 pages)
      313 Fields
      ~ 15k Users (For an intranet portal? That's heavy.)
      ~ 195 431 Pages (At least that's the current AUTOINCREMENT)
       
      I think we came to a point where ProcessWire isn't as scalable anymore as it used to be. Our latest research measured over 20 seconds of load time (the time PHP spent scambling the HTML together). That's unacceptable unfortunately. We've implemented common performance strategies like:
      We're running on fat machines (DB server has 32 gigs RAM, Prod Web server has 32gigs as well. Both are running on quadcores (xeons) hosted by Azure.
      We have load balancing in place, but still, a single server needs up to 20 sec to respond to a single request averaging at around about 12 sec.
      In our research we came across pages that sent over 1000 SQL queries with lots of JOINs. This is obviously needed because of PWs architecture (a field a table) but does this slow mySQL down much? For the start page we need to get somewhere around 60-80 pages, each page needs to be queried for ~12 fields to be displayed correctly, is this too much? There are many different fields involved like multiple Page-fields which hold tags, categories etc.
      We installed Profiler Pro but it does not seem to show us the real bottleneck, it just says that everything is kinda slow and sums up to the grand total we mentioned above.
      ProCache does not help us because every user is seeing something different, so we can cache some fragments but they usually measure at around 10ms. We can't spend time optimising if we can't expect an affordable benefit. Therefore we opted against ProCache and used our own module which generates these cache fragments lazily. 
      That speeds up the whole page rendering to ~7 sec, this is acceptable compared to 20sec but still ridiculously long.
      Our page consists of mainly dynamic parts changing every 2-5 minutes. It's different across multiple users based on their location, language and other preferences.
      We also have about 120 people working on the processwire backend the whole day concurrently.
       
      What do you guys think?
      Here are my questions, hopefully we can collect these in a wiki or something because I'm sure more and more people will hit that break sooner than they hoped they would:
       
      - Should we opt for optimising the database? Since >2k per request is a lot even for a mysql server, webserver cpu is basically idling at that time.
      - Do you think at this point it makes sense to use ProcessWire as a simple REST API?
      - In your experience, what fieldtypes are expensive? Page? RepeaterMatrix?
      - Ryan, what do you consider as the primary bottleneck of processwire?
      - Is the amount of fields too much? Would it be better if we would try to reuse fields as much as possible?
      - Is there an option to hook onto ProcessWires SQL builder? So we can write custom SQL for some selectors?
       
      Thanks and lots of wishes,
      Pascal from Mobile Trooper
       
       
    • By Noel Boss
      ProcessWire & Vue.js — a Lovestory
      Introducing the all new ICF Conference Website
        The new ICF Conference Page — Fearless
      » What would happen if we were equipped to fearlessly face the daily challenges and live a life without fear? «
      This question is at the core of our next ICF Conference in 2019 in Zurich. Its also the question we set out to answer in terms of developing the new website; the all new ICF Conference website is our most advanced website in terms of technology, designed to take advantage of the latest web-technologies.
      Its a brand new design powered by a lean setup, using ProcessWire for easy content management and a slick frontend based on Vue.js, Quasar and a heavily customized Uikit theme.
        Technology-stack — From backend to frontend, technologies that are fun, easy and fast to develop with We built on the ICF Ladieslounge website as a solid foundation and took our learnings from building our last Conference Booklet PWA (Progressive Web App) and applied it to the new website.
      Some highlights of the new ICF Conference website:
      Completely decoupled backend and frontend Custom design based on Uikit frontend framework Changing of languages happens instantly, no page-reload required Easy content updates thanks to ProcessWire All data is transferred using a single request returning custom JSON



      » Continue reading on Medium
      And please don't forget to clap and share: 

       
×
×
  • Create New...