FTLRalph

@csskevin hey, any update on this? Don’t mean to be pushy just curious whats up

Can confirm, is not working at least for me with WP 5.5.1 (https://sticknodes.com/stickfigures/) – click an image thumbnail, nothing happens

Console:

Uncaught ReferenceError: hide is not defined
    start https://sticknodes.com/wp-content/plugins/wp-lightbox-2/js/dist/wp-lightbox-2.min.js?ver=1.3.4.1:1
    start https://sticknodes.com/wp-content/plugins/wp-lightbox-2/js/dist/wp-lightbox-2.min.js?ver=1.3.4.1:1
    onClick https://sticknodes.com/wp-content/plugins/wp-lightbox-2/js/dist/wp-lightbox-2.min.js?ver=1.3.4.1:1
wp-lightbox-2.min.js:1:15555
    start https://sticknodes.com/wp-content/plugins/wp-lightbox-2/js/dist/wp-lightbox-2.min.js?ver=1.3.4.1:1
    forEach self-hosted:206
    start https://sticknodes.com/wp-content/plugins/wp-lightbox-2/js/dist/wp-lightbox-2.min.js?ver=1.3.4.1:1
    onClick https://sticknodes.com/wp-content/plugins/wp-lightbox-2/js/dist/wp-lightbox-2.min.js?ver=1.3.4.1:1
    onClick self-hosted:1208

@gagan0123 I’ll check this later when I can, and thank you, but point is the 404.php is still logging a lot – more than “normal” I would say.

So something *else* is going on, and that’s why I’m just wondering if you or anyone else would know how to actually retrive what call to what file/directory it is that’s triggering a specific call to the 404.php page

@gagan0123 thanks for taking the time to help

okay so I tried the htaccess on my live site now vs just a local test site

it’s tough to tell if it’s working, because the site is live with many users, there are still occasional logging of the 404 page being accessed but I *think* less than it would be otherwise?

is there a way to also have the 404.php error_log out what exactly is being requested, filename or something, because having that in the log would help identify if these are valid 404’s or what

@tobifjellner this happens when posts/comments contain broken images, user-content

if the html has a “dead image”, the 404.php theme file is run but not displayed

so what I’m asking here basically is, this isn’t normal behavior right? Where is WP determining to fetch the theme’s 404 file, so I can maybe fix this?

@gagan0123 thanks even though I still do not want to hack at the htaccess (unless every WP installation needs this “fix” which I doubt) I tried it but still getting the theme’s 404.php file running if a broken img is encountered-

@tobifjellner I appreciate the help. I might have to resort to this, but this isn’t actually fixing the underlying condition. Right? Again I assume this “loading the 404 template behind the scenes on every broken image found in a page”-thing isn’t supposed to actually be a thing.

@gagan0123 Thanks for the reply

I’ve been using the Query Monitor plugin, didn’t see anything helpful. But I just installed the Template one, still nothing of interest?
This is loading index.php / homepage:

View post on imgur.com

There is 1 broken image on the page, the Console shows this:

View post on imgur.com

But the page loads fine. Meanwhile in my error_log, I have the theme’s 404.php printing out “hello” aka the template is being tapped to run.

Removing the .htaccess file shows the normal Apache 404 “not found” page.

I guess what I’m asking is, WHERE is it determined by WordPress to fetch a theme’s 404 page?

@joyously I’m honestly not sure and just asking, but is this the desired behavior? If you have a user-written post and they embed an image in it that doesn’t exist, the theme’s 404.php should execute (but not display) on the loading of that post on the front end because it encountered a “broken image”?

@howdy_mcgee (I don’t know if I have to @ for you to see reply lol)

thanks again

even if this is the case, I don’t see how it would help in the end, I need the class structure, my entire plugin is structured this way-

the example above is pretty non-class-based and it’s exactly the situation it is now

the ” has_action( ‘my_action2’ ) ” is the kicker for me because that shows it SEES the action exists during runtime, but is just not calling the function hooked to it? I can’t understand how both of those can be a possibility

@howdy_mcgee oof sorry for the late reply, I really appreciate the time you took to try to help me understand this

so I’m reading over this, and really trying to understand but, you decoupled it from the class structure I got going and I can’t really apply it logically for a fix because, things seem pretty correct?

here is the scenario in a simple example, I hope:

OTHER PLUGIN, the trigger

static function doSomething()
{
  do_action( 'my_action_1' );
  do_action( 'my_action_2' );
}

MY PLUGIN

construtor
{
  add_action( 'my_action_2', myAction2 );
  add_action( 'my_action_1', myAction1 );
}

myAction1()
{
  print( 'print from action1' );
  do_action( 'my_action_2' ); // this is the call that never executes
}

myAction2()
{
  print( 'print from action2' );
}

Output as it is now:

print from action1
print from action2

What it SHOULD be…because myAction1() calls do_action for myAction2():

print from action1
print from action2
print from action2

For some reason, action1 cannot “see” action2 as if it doesn’t exist. But, I don’t know how to make it exist any more than it does?

EDIT: Bonus points, adding has_action( ‘my_action2 ‘ ); under the line commented up above produces 1 when the add_action() exists. If I comment it out, it is 0. So it KNOWS the action/hook is there, it’s just not firing?

• This reply was modified 4 years, 8 months ago by FTLRalph.
• This reply was modified 4 years, 8 months ago by FTLRalph.

@joyously Thanks for your replies.

“Cloning the DB” what I mean is I export the database from phpmyadmin. I then go to my local server via WAMP and import it into a blank DB. Connect a new WP installation to it, and the site is cloned. Using my hosts file to redirect mydomain.com to localhost I can emulate being on the live site.

I’ve done this many times. So what I’m proposing here is I’d do the same, but in reverse.

After doing that ^ and making all of my changes locally, I’d export from phpmyadmin again, upload this DB to a second/blank DB on my *live* server, and once complete, simply point wp-config.php on my life sit to this new database which should be identical+my changes.

It’s essentially a migration plugin, I just don’t trust a migration plugin. There is a LOT of data and finicky plugins and I really don’t even want to introduce WP in a new folder, even if temporary, as I can see that borking permalinks and everything.

@joyously Yes I forgot to mention. I’m “willing” to lose a little user content for the small period of time. I’ll use a maintenance mode plugin as well, though in past experience (and I don’t know how) a very small selection of visitors get by it. Whether it be because they were already on the site or what, but I can see activity on pages within the site (very, very minimal, but it’s there).

Anyway. I’m leaning towards
1) Cloning the site locally
2) Performing all plugin/widget/page/layout/DB changes
3) Cloning THAT DB onto a second DB on my LIVE server
4) Changing wp-config.php on live server to point to “new” DB

I’m just concerned
1) Compatibility with exported DB from my localhost to live server. I’ve gone from live server -> localhost but never the other way around. While my phpmyadmin / MariaDB versions are close, they’re not identical.
2) Worried WP might think it’s a new installation once I change wp-config “for some reason” (never know with this stuff)

But I think that’s my cleanest option.
Again, any input/advice from people that have been there done that is appreciated. I’m still planning for this in the upcoming week.

So just to keep this thread updated, I was able to
1) drop the fulltext indexes
2) convert the table to innodb
3) revamp search to use LIKE and not MATCH...AGAINST since no more fulltext indexes

And unfortunately 24 hours later same deal, pretty much, load very high and commenting out that query relieves it somewhat.

Honestly the inefficient searching (LIKE) may now be contributing to the problem, gotta keep tinkering

Yes that’s right.

I’m just testing on my local install (with 10.1.x) to test if this is even a viable solution.

After trying again today, I was able to convert the table to InnoDB and preserve all the indexes (had to change file_display_name from varchar(300) to (255) beforehand).

Searching works, and the table is InnoDB. I’m thinking of trying this on the live site.

I’m Googling around and I see:
Full-text indexes can be used only with MyISAM and Aria tables, from MariaDB 10.0.5 with InnoDB tables and from MariaDB 10.0.15 with Mroonga tables, and can be created only for CHAR, VARCHAR, or TEXT columns.

Thanks again for all the ideas and help. I’m going to look into updating to at least that version of MariaDB and give Innodb on this table go.
The alternative is I can leave it as it is now, remove the fulltext indexes, and change the searching from match...against to like