jeff9315

Perfect!! Worked like a charm. Thanks once again for your AWESOME support!!!!

Jeff

What I meant was that I could have probably created a different template for each category. Then I wouldn’t have needed conditional logic. Although that would have been so many templates it would have been unwieldy. My PHP code is better when you have a lot of different query/order combinations. But if you only have a couple, then the new template enhancements will be great.

My PHP code was my first attempt at a plugin (and my first PHP code in about 10 years) so, although it was very simplistic, I’m pretty proud of it ??

Never mind … the solution is this where clause:

WHERE post_status <> 'inherit'

FIrst off David … I’d like to REALLY thank you for all your help on this. You really went above and beyond. I know I was really getting discouraged trying to find a solution but you helped me debug it.

I finally determined that the plugin was “PP Content Teaser” that caused the issue. Or at least the interaction between that plugin and yours. “PP Content Teaser” is an addon to the “Press Permit” plugin. So I need to contact that developer to let him know the issue. For me, the good news is that although Press Permit is essential to my site the “PP Content Teaser” isn’t necessary at all (I just never got around to deactivating it).

Deactivating “PP Content Teaser” dropped the memory footprint from 190 MB to below 70 MB. I haven’t tested it to see how low I can go. But looking at the memory debugging lines I put in, I suspect I can go to 50 MB.

Thanks again … Jeff

OK … The wp_postmeta table has 4810 rows and is 848 KB … according to WP Cleanup Optimizer.

wp_postmeta* 4810 InnoDB 848.0 KB

OK … I modified the memory stats per your request. Plus I divided by (1024*1024) and rounded to the nearest 100th MB to make it easier to read.

Here’s an interesting experiment … I used only the “Board Minutes” category. There are 12 documents in that category and it does NOT filter or sort by any custom fields. I increased the numberposts parameter from 1 to 19 and then didn’t specify numberposts at all for the last iteration. It looks like there is about a 3-5 MB increase of real memory for each iteration EVEN after it goes beyond 12. Then, for the final iteration (when I do NOT specify the numberposts), there is a huge jump of over 100 MB so that it needs 244 MB.

[mla_gallery mla_style="sc-list" columns=1 attachment_category="Board Minutes" post_mime_type=application/pdf link=file mla_item_width="45" orderby="title" order="DESC" ] ...

numberposts=01 ...
php_increase ~ 3.17M, real_increase: 3.5M, real_memory: 48.25M

numberposts=02 ...
php_increase ~ 3.45M, real_increase: 3.25M, real_memory: 51.5M

numberposts=03 ...
php_increase ~ 2.56M, real_increase: 2.5M, real_memory: 54M

numberposts=04 ...
php_increase ~ 3.64M, real_increase: 4M, real_memory: 58M

numberposts=05 ...
php_increase ~ 3.43M, real_increase: 3.5M, real_memory: 61.5M

numberposts=06 ...
php_increase ~ 3.81M, real_increase: 3.75M, real_memory: 65.25M

numberposts=07 ...
php_increase ~ 5.2M, real_increase: 5.25M, real_memory: 70.5M

numberposts=08 ...
php_increase ~ 4.96M, real_increase: 5.75M, real_memory: 76.25M

numberposts=09 ...
php_increase ~ 5.09M, real_increase: 5.5M, real_memory: 81.75M

numberposts=10 ...
php_increase ~ 5.51M, real_increase: 5.75M, real_memory: 87.5M

numberposts=11 ...
php_increase ~ 5.93M, real_increase: 6.25M, real_memory: 93.75M

numberposts=12 ...
php_increase ~ 6.29M, real_increase: 6.5M, real_memory: 100.5M

numberposts=13 ...
php_increase ~ 5M, real_increase: 5.25M, real_memory: 105.75M

numberposts=14 ...
php_increase ~ 4.99M, real_increase: 5.25M, real_memory: 111M

numberposts=15 ...
php_increase ~ 4.98M, real_increase: 5.25M, real_memory: 116.25M

numberposts=16 ...
php_increase ~ 4.94M, real_increase: 5M, real_memory: 121.25M

numberposts=17 ...
php_increase ~ 4.94M, real_increase: 5.25M, real_memory: 126.5M

numberposts=18 ...
php_increase ~ 4.94M, real_increase: 5.25M, real_memory: 131.75M

numberposts=19 ...
php_increase ~ 4.94M, real_increase: 5.25M, real_memory: 137M

numberposts NOT SPECIFIED!!!
php_increase ~ 106.4M, real_increase: 107.5M, real_memory: 244.5M

Then I ran it with ONLY one invocation on the page … without a numberposts and it’s still high but not as bad.

php_increase ~ 13.77M , real_increase = 116.5M , real_memory = 161.25M

I still want to see if I can look at the postmeta table per your request. I also want to try a completely clean install on the same host … no posts, pages or data except for the 12 “Board Minutes” and what’s necessary to run this test. And no plugins other than yours. But I need to see if I have enough space on the server for an extra WordPress installation.

Thanks for looking into this!!!!
Jeff

OK … I changed the order I’m executing them in to see if that tells us anything interesting … Board Resumes starts out the same as the previous run started. The 2nd Board Resumes jumps up by 30 MB. Governing Docs (11th invocation) jumps up a huge amount. And Newsletter 2015 (13th invocation) jumps up again.

Board Resumes – 2016-03
before mla_gallery_shortcode memory = 45743688 , real_usage = 46923776

Board Resumes – 2015-12
before mla_gallery_shortcode memory = 50933712 , real_usage = 78381056

Financial Reports
before mla_gallery_shortcode memory = 53592288 , real_usage = 81788928

Town Hall Statuses
before mla_gallery_shortcode memory = 57633232 , real_usage = 94896128

Town Hall Meeting Notes
before mla_gallery_shortcode memory = 58536696 , real_usage = 94896128

Town Hall Agendas
before mla_gallery_shortcode memory = 59449840 , real_usage = 94896128

Forms
before mla_gallery_shortcode memory = 60366400 , real_usage = 94896128

Contracts
before mla_gallery_shortcode memory = 61277592 , real_usage = 95158272

Board Agendas
before mla_gallery_shortcode memory = 61299336 , real_usage = 95158272

Board Minutes
before mla_gallery_shortcode memory = 63950488 , real_usage = 95420416

Governing Documents
before mla_gallery_shortcode memory = 75273216 , real_usage = 186122240

Event Flyers
before mla_gallery_shortcode memory = 80476072 , real_usage = 186646528

Newsletter – 2015
before mla_gallery_shortcode memory = 92513624 , real_usage = 223084544

Newsletter – 2014
before mla_gallery_shortcode memory = 101331360 , real_usage = 224133120

Oh … I had forgotten to mention one detail … I do NOT have any issues when I view the page when I’m logged in as Admin. Only when I’m logged in as a normal user. I’m curious if you had tested under both scenarios.

Adding your debugging code (which I am HUGELY appreciative of since I’ve been trying to figure out how to get that info), you can see that the memory looks fine in Admin mode — starts relatively small and doesn’t change much. However, when I’m logged in as a normal user, it starts out about the same. Then it jumps up significantly at Financial Reports (8th invocation) and then again at Board Resumes (11th invocation). But it’s MOSTLY the real_usage that’s jumping up.

Logged in as Admin

Town Hall Statuses (1st invocation)
before mla_gallery_shortcode memory = 46275104 , real_usage = 48234496

Newsletter – 2014 (last invocation ... #14)
before mla_gallery_shortcode memory = 49596064 , real_usage = 51380224

So, you can see when I’m logged in as Admin, there’s no major increase … Just 3 MB.

Logged in as a normal user

Town Hall Statuses
before mla_gallery_shortcode memory = 45742816 , real_usage = 46923776

Town Hall Meeting Notes
before mla_gallery_shortcode memory = 49056440 , real_usage = 58720256

Town Hall Agendas
before mla_gallery_shortcode memory = 49963984 , real_usage = 60293120

Forms
before mla_gallery_shortcode memory = 50876200 , real_usage = 61079552

Contracts
before mla_gallery_shortcode memory = 51780496 , real_usage = 62128128

Board Agendas
before mla_gallery_shortcode memory = 51801136 , real_usage = 62128128

Board Minutes
before mla_gallery_shortcode memory = 54634768 , real_usage = 82837504

Financial Reports
before mla_gallery_shortcode memory = 66486536 , real_usage = 176685056

Governing Documents
before mla_gallery_shortcode memory = 70047352 , real_usage = 177209344

Event Flyers
before mla_gallery_shortcode memory = 75239336 , real_usage = 177733632

Board Resumes – 2016-03
before mla_gallery_shortcode memory = 87201072 , real_usage = 217579520

Board Resumes – 2015-12
before mla_gallery_shortcode memory = 89846168 , real_usage = 217841664

Newsletter – 2015
before mla_gallery_shortcode memory = 92476080 , real_usage = 218103808

Newsletter – 2014
before mla_gallery_shortcode memory = 101308224 , real_usage = 219152384

The problem turned out to be the PressPermit plugin. The author has since posted a fix for it.

I forgot to mark this resolved.

The solution was really obvious in hindsite. My return statement should have been:

return do_shortcode($my_shortcode);

I’ve simplified it so that the only thing in the template is {@first_name}.
The shortcode is [pods name="resident" template="Resident Index" limit="-1"].

My Detail listing works fine if I’m only displaying one entry. But it doesn’t work if I use it to "List Multiple Pod Items".

I’ve tried 2 different templates … one for “Resident Details” and one for “Resident Index”.

I THINK (but I have to try this again that creating a different Pod worked fine (naming it “Res2” instead of “Resident”. But deleting the “Resident” Pod and creating a new “Resident” Pod (using the same name) also caused the same issue. But I need to try all that again to verify that. Do you think the items defined with the Resident Pod could somehow be corrupted? Since this a test site, I’m thinking about refreshing it and starting over. But I want to make sure you don’t want me to send you anything in case there’s a bug in the system you should be aware of.

Thanks … Jeff

Hi Nick … I REALLY appreciate your getting back to me as quickly as you did. This plugin looks really awesome. I had already read all about the event template tags but the key was the “Compact List”. When I tried that I was in “Preview Mode” … and it didn’t seem to do anything. When I actually did an update and viewed the page, it was EXACTLY what I wanted!!!!

Thanks for such a truly awesome plugin … I’ll be buying the Pro version in a week or so.

Thanks … Jeff

OK … I think the problem for me was that I needed to specify “Any” under “Post Status”. I had used “Publish” because I thought that meant any post that was published. Maybe I was wrong.

I wonder if I have to do something to allow this plugin to see my specific Custom Post Statuses so that they show up under “Post Status”.

Here’s what the other developer did on his local site and it worked … it’s different from your change. However, I just tried this change on my site and it still doesn’t work.

change line 558:
from:

$qargs = array(
  'post_status' => 'publish',
  'offset'      => 0,
  'numberposts' => 1,
);

to:

$qargs = array(
  'post_status' => 'publish',
  'offset'      => 0,
  'numberposts' => 1,
  'suppress_filters' => false,
)