Jump to content
prestoav

[Solved] Error after upgrade - Blog Module 2.4.0 to 2.4.5

Recommended Posts

Hi everyone,

PW version 3.0.123

I've recently tried to upgrade the Blog module in an installation from 2.4.0 to 2.4.5 and now get the following errors when trying to visit Blog > Posts in admin:

Fatal Error: Uncaught Error: Call to a member function count() on null in /MYSITE/site/modules/ProcessBlog/ProcessBlog.module:1299
Stack trace:
#0 /MYSITE/site/modules/ProcessBlog/ProcessBlog.module(1421): ProcessWire\ProcessBlog->renderItemsSummaries(Object(ProcessWire\PageArray))
#1 /MYSITE/site/modules/ProcessBlog/ProcessBlog.module(1989): ProcessWire\ProcessBlog->renderItemsList(Object(ProcessWire\PageArray))
#2 /MYSITE/wire/core/Wire.php(380): ProcessWire\ProcessBlog->___executePosts()
#3 /MYSITE/wire/core/WireHooks.php(723): ProcessWire\Wire->_callMethod('___executePosts', Array)
#4 /MYSITE/wire/core/Wire.php(442): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessBlog), 'executePosts', Array)
#5 /MYSITE/wire/core/ProcessController.php(333): ProcessWire\Wire->__call('executePosts', Array)
#6 /MYSITE/wire/core/Wire.php(380): ProcessWire (line 1299 of /MYSITE/site/modules/ProcessBlog/ProcessBlog.module)

This error message was shown because: you are logged in as a Superuser. Error has been logged.

I can see posts in Blog > Dashboard and all seems to work still on the front end.

Anyone else seen this or know of a fix?

Share this post


Link to post
Share on other sites

Does your template have a page-reference field called blog_tags?

Share this post


Link to post
Share on other sites
16 minutes ago, Jan Romero said:

Does your template have a page-reference field called blog_tags?

Hi Jan and thanks for replying.

I just checked the site and there is no field in the template with that name. There is one in the site, added by the module, but it is not in use in any template or assigned to any template in PW.

Share this post


Link to post
Share on other sites
2 hours ago, prestoav said:

Call to a member function count() on null in /MYSITE/site/modules/ProcessBlog/ProcessBlog.module:1299

This tries to count the items in blog_tags and fails because the field isn’t available. I’m not familiar with the module, but it appears to assume all blog posts (?) to have that field, so just adding the field to the relevant template should fix this particular error.

Share this post


Link to post
Share on other sites
4 minutes ago, Jan Romero said:

This tries to count the items in blog_tags and fails because the field isn’t available. I’m not familiar with the module, but it appears to assume all blog posts (?) to have that field, so just adding the field to the relevant template should fix this particular error.

Yup, you were spot on Jan, thank you. The blog_tag field had been removed form the template in PW. Once restored the admin started working again. I'll mark this solved and raise a bug report for the module.

Thanks again.

  • Like 1

Share this post


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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Greg Lumley
      Hi! I'm busy building a blog into my first test/learning/free/clients/project 😁

      I've had a look at all the blog examples and there seem to be different ways of doing it. (the point of Processwire, I know)

      It seems this is generally how it's done:
      Master Blog Page
        - Blog Post Child Page
        - Blog Post Child Page
        - Blog Post Child Page What I'm particularly interested in is the Categories. What would you advise?
      Repeater Field?
      Tags?

      I think I've even seen Categories set up as Children of a master Category page too. The pages were hidden containing no 

      What would you recommend? 

      Thank you! 
      Greg. 

      Bare with me, I'm bashing my way through while I learn. 
    • By muzzer
      Existing PW site version 2.7.2 core running on php7.1. Site is perhaps 7 yrs old and never misses a beat. Can't speak highly enough about this solid version, but....
      As new php versions are released (v8 in the next year I think?) and each seems to get quicker I'm looking at upgrading to php7.3 or 7.4 and upgrading the site to PW v3.x.
      I've been away from the forums since v3 was released so don't know much about it. I guess it's stable as it's been around for ages now, but what I'm wondering is:
      what are the real advantages of upgrading to v3 for a site which is actively used but with only periodic development. And what are the disadvantages if any? Is there any speed impact (good or bad) in either general site speed under 3.x or admin-use speed/ease of use? any issues with either PW version with newer php versions (>7.1) I should know about? is there any good write-ups/vids about new features etc of v3 compared to v2.7? Thank you
       
    • By MateThemes
      Hello everyone!
      I use ryans blog site profile to build my template around it. I use my mamp pro setup with php 7, mysql 5 and apache server. On my local setup the following code works fine:
      <?php foreach(page()->children as $category): ?> <a class='uk-link-reset' href='<?=$category->url?>'> <div class='uk-card uk-card-default uk-card-hover uk-card-body'> <h3 class='uk-card-title uk-margin-remove'><?=$category->title?></h3> <span class='uk-text-muted'><?=$category->numPosts(true)?></span> </div> </a> <?php endforeach; ?> It is the same code as ryan used it, only my css classes. On my live server with the same setup as mamp pro i got following error:

      Does anyone have the same error in this context?
      Thank you very much for your help!
    • By Violet
      Here I'm introducing FlipFall Magazine, our multi-topic blog. It used to run on Wordpress but we recently switched it to ProcessWire. This was done the usual way we do it when converting our sites: install ProcessWire in a subfolder of the original Wordpress site under a hard-to-guess name, set up the new site there, then move content over manually, inspecting and updating each article as needed. After the ProcessWire site was ready, when we un-installed the Wordpress one and moved the ProcessWire site up one level to the document root, and... done.
      We used the W3CSS framework because it handles the responsive breakpoints so well (no extra work for us 😉), and it tends to default to a clean modern look.
      We wanted full control over the back end of the site and do customized things without having to hire a developer.  As FlipFall has grown, the ability to have in-house back-end control has become even more important.
      Case example: Ad partners - we now can quite easily, if we wish, place different ads on different topics on this blog at a moment's notice - no need to hire a developer. Changes like this can be implemented in-house right away. The fact that we can easily incorporate this sort of thing is really nice when we're talking with potential ad partners.
      Helpful features of ProcessWire during this experience:
      The ability to export and import fields in PW was key here. We had a few other article-style sites I had done in PW recently, so having the same types of templates was very helpful. We were able to export fields and templates from our existing sites and import into FlipFall as a starting base point. No need to re-invent the wheel here! Another helpful ability of PW was when we were dealing with the categories. We built the site without category templates (but with the category page field), then added the templates in later as needed - no disruption. In other words, a template-less page field worked perfectly for the categories until we needed the template, then we just created the template. Not every feature of the site needs to be thought out in absolute full beforehand, some can be added in later as needed. Very extensible and convenient. Internal links within blog posts worked well using the page select option in the link button on the editor. When moving out of staging folder and into document root, the links auto-updated, which was nice. Creating new articles is a breeze, because under PW our fields are now customized for our needs: we created all of the fields we need and none of the ones we don't. Again, this is unlike most blogging CMS's, where they try to guess what you want (and usually get it wrong). Even for people who are solely doing blogs/article sites, I feel that ProcessWire is a much better option than most blog-specific platforms, because of PW's flexibility.  The only thing I miss about Wordpress is the ability to auto-schedule post publication, which for the serious blogger is important. For example, there were some occasions on some of our other blogs where we needed to schedule posts to auto-publish at 3:01am Eastern Time to allow a time-sensitive post to come out as early in time of day as possible on publication date (3:01 am US Eastern time ensures it's that same day 12:01 am on Pacific time). We were delighted to see that ProcessWire is much, much lighter on resources of the hosting environment than the same site on Wordpress - we could see this empirically on our web hosting stats before and after the switch.
    • By Peter Knight
      Occasionally when I goto Modules > Upgrades I get the following type of error.
      There's actually about three of them and each one mentions a different line. In the example below, line 266 is
      $new = version_compare($versions[$name]['remote'], $versions[$name]['local']);  
      ( ! ) Notice: Undefined index: local in /Users/peterknight/Sites/mysite.com/site/assets/cache/FileCompiler/site/modules/ProcessWireUpgrade/ProcessWireUpgradeCheck.module on line 266 Call Stack # Time Memory Function Location 1 0.0011 405040 {main}( ) .../index.php:0 2 0.2602 5197688 ProcessWire\ProcessPageView->execute( ) .../index.php:55 3 0.2602 5198064 ProcessWire\ProcessPageView->__call( ) .../index.php:55 4 0.2602 5198064 ProcessWire\WireHooks->runHooks( ) .../Wire.php:442 5 0.2603 5198480 ProcessWire\ProcessPageView->_callMethod( ) .../WireHooks.php:733 6 0.2603 5198480 ProcessWire\ProcessPageView->___execute( ) .../Wire.php:383 7 0.3009 5463888 ProcessWire\Page->render( ) .../ProcessPageView.module:209 8 0.3009 5463944 ProcessWire\Page->__call( ) .../ProcessPageView.module:209 9 0.3009 5463944 ProcessWire\WireHooks->runHooks( ) .../Wire.php:442 10 0.3015 5465248 ProcessWire\PageRender->renderPage( ) .../WireHooks.php:834 11 0.3015 5465624 ProcessWire\PageRender->__call( ) .../WireHooks.php:834 12 0.3015 5465624 ProcessWire\WireHooks->runHooks( ) .../Wire.php:442 13 0.3016 5466040 ProcessWire\PageRender->_callMethod( ) .../WireHooks.php:733 14 0.3016 5466040 ProcessWire\PageRender->___renderPage( ) .../Wire.php:383 15 0.3032 5470760 ProcessWire\TemplateFile->render( ) .../PageRender.module:514 16 0.3032 5470816 ProcessWire\TemplateFile->__call( ) .../PageRender.module:514 17 0.3032 5470816 ProcessWire\WireHooks->runHooks( ) .../Wire.php:442 18 0.3033 5471848 ProcessWire\TemplateFile->_callMethod( ) .../WireHooks.php:733 19 0.3033 5471848 ProcessWire\TemplateFile->___render( ) .../Wire.php:380 20 0.3036 5493112 require( '/Users/peterknight/Sites/mysite.com/site/assets/cache/FileCompiler/site/templates/admin.php' ) .../TemplateFile.php:287 21 0.3038 5493616 require( '/Users/peterknight/Sites/mysite.com/wire/modules/AdminTheme/AdminThemeUikit/controller.php' ) .../admin.php:15 22 0.3038 5495120 require( '/Users/peterknight/Sites/mysite.com/wire/core/admin.php' ) .../controller.php:15 23 0.3085 5586144 ProcessWire\ProcessController->execute( ) .../admin.php:135 24 0.3085 5586200 ProcessWire\ProcessController->__call( ) .../admin.php:135 25 0.3085 5586200 ProcessWire\WireHooks->runHooks( ) .../Wire.php:442 26 0.3085 5586616 ProcessWire\ProcessController->_callMethod( ) .../WireHooks.php:733 27 0.3085 5586616 ProcessWire\ProcessController->___execute( ) .../Wire.php:380 28 0.3108 5596744 ProcessWireUpgrade->execute( ) .../ProcessController.php:333 29 1.2224 8773000 ProcessWireUpgradeCheck->getVersions( ) .../ProcessWireUpgrade.module:187 30 1.2227 8776256 ProcessWireUpgradeCheck->getModuleVersions( ) .../ProcessWireUpgradeCheck.module:185 I've been living with it for a while and while it doesn't seem to stop me upgrading etc, I'd love to fix it.
      Anyone recognise this type of error?
×
×
  • Create New...