@MichaelEcklund look for questions about widgets on the site. I am sure I gave a long answer at least once. tl;Dr; it is a template from which new "objects" of the widget are creeated

tbh something feels off about needing to know the widgets ID

@TomJNowell I see

How to debug slow queries? cloudup.com/cGJ6DwrvAd2

Can this be because of plugins? or Heavy server resources usage?

Almost all queries on the page are slow

@bravokeyl There are some insanely poor-written plugins that hook into the queries which slow the process

One for example is the redux framework, which will PAUSE the loading unless it can access a JSON file on their even slower server

You have to either wait for the request to finish, or wait for curl to timeout.

@MarkKaplun For some reason I actually have an experience in which I got different results from $_REQUEST than $_POST

never figured out why.

Which is why you should not use it, but for that question it was unlikely to be the cause of the problem

at least php defines $_request to aggregate all

@MarkKaplun It was a case in which I couldn't get ANY data from $_POST, so I had to use $_REQUEST

Later on I turned it into a rest-api and got rid of the issue, but never understood the problem

@MarkKaplun well I realize that, but shouldn't I be expecting to see the actual instance number, if I have the widget assigned to a sidebar and I'm previewing it within the Theme Customizer? Isn't that essentially a representation of the frontend? It works fine on the frontend.

@TomJNowell So I've made a class to store store objects once they've been retrieved. So that I can check for those objects in the class before attempting to fetch from DB. These are WP objects, which I've customized into my own objects that work for what I'm trying to do with my framework. so it makes sense to check to see if the object already exists before doing all that work of fetching it from DB and customizing the object.

So for example, when a Widget is instantiated, internally, the settings are already available. So I stick them into the class. I assign them in an associative array by $widget->id_base and $widget->number

so later on, I can conditionally load files needed by that widget and specifically a particular instance of that widget.

instead of fetching widget settings multiple times, it only happens one time

Does anyone ever look at code and just be like: "how does that even work?"

@bravokeyl sometimes your queries are slow because your DB server is slow

you can't throw a MySQL server on a watch and expect queries to run quickly

just as you can't expect the DB on a shared server to be fast

and ofcourse it could be that your queries are slow because a caching plugin is intercepting them and using the file sytem, and the file system is slow

@MichaelEcklund so basically you've duplicated the functionality of WP_Cache?

All of that stuff already gets cached by WP_Cache, posts, post meta, options, they all get stored in WP_Cache to prevent making a second trip to the DB

and if you have an object cache, it'll store them there, so on the next request it won't touch the DB and goes to the in memory cache Redis/Memcache/etc provide

that's why object cache dropins give such a massive speed boost

and it's where options that have autoload set get saved

as for which files to load

@TomJNowell How does WP_Cache work? Can I fabricate core objects as my own object and cache that?

so like for example, WP_Post doesn't provide a permalink property. So in my object, I fetch the permalink, and assign it as a property to the post object. So my object name is no longer called WP_Post

That way in my code later on, I can simple just do $post_object->permalink instead of get_permalink( $post_object->ID );

@MichaelEcklund what do you mean by fabricate core objects?

why would you modify the WP_Post objects?

I would stop doing that

also keep in mind that you're introducing potential compatibility issues

if these things need to be cached they're very likely already transparent cached by WP_Cache

I'm not modifying it I guess. Maybe fabricate was the wrong word to use.

e.g. calling get_post(2); get_post(2); does not trigger 2 sets of queries, only 1

I'm cloning the object into my own object, and then customizing properties.

@MichaelEcklund it still sounds bad, stop doing that and just use get_permalink etc

don't be cloning objects

wrap objects if you must in a wrapper class that takes a WP_Post object

What do you mean

but even then, doing stuff like that with the permalinks means the filters don't run

very very bad, stop cloning things

much technical debt

why wouldn't the filters run? I'm still calling get_permalink();

the first time yes

but not the following times

and you're messing with internal core objects

I don't understand

do not mess with core objects, don't monkey patch them, don't replace them, don't clone them and do weird things to them

at most, removing a core object and placing a sub-classed version of it back in place is a hacky way of doing things that's necessary in 0.01% of cases

but it sounds like what you need to do needs the wrapper/adaptor pattern

What's the difference if I do $post_object->permalink = get_permalink( $post_object->ID ); and then just use $post_object->permalink; everywhere, versus repeatedly calling get_permalink( $post_object->ID ); elsewhere?

@MichaelEcklund get_permalink is a standard API maintained by Core with built in caching and filters with known behaviour

whereas now you're facing problems because of this approach that you wouldn't normally face in WP development because they're usually non-issues

ya but doing it that way also opens the possibility of passing the incorrect ID

e.g. you're problems with widget IDs and mapping your custom objects etc

@MichaelEcklund wrapper objects

encapsulation, wrappers, adaptors

all standard entry level computer science

Can you link me an example to what you're talking about?

I guess I dont know what that stuff means

stackoverflow.com/questions/889160/…

I've had great success using my own objects this way though.

it's an object that you would pass a post object to

then call the wrapper object

@MichaelEcklund not based on the questions you ask here, you're having to tackle problems and issues you shouldn't need to

like what

imagine there's a very busy person

he/she hires a go between

you now talk to the go between

Oh, so you mean to just extend WP_Post ?

not the original person

no, extending WP_Post is inheritance, sub-classing

still bad

aka the very busy person was replaced by a new very busy person with an extra arm or ear

I'm talking about something that wraps the post object

the post object itself remains intact and unchanged

you interact with the wrapper

like a shell surrounding it

a front of house

yeah is there a code example somewhere

and adapter, a facade, a wrapper, container, go between, middle man

I see one on wikipedia but its like super complex

class TomjnPost {
	private $post;
	public function __construct( \WP_Post $p ) {
		$this->post = $p;
	}

	public function permalink() {
		return get_permalink( $this-post->ID );
	}
}

you don't have to modify objects to achieve your goals

or change the very nature of object types

that's basically what im doing

in your example

you can encapsulate things, and use composition to achieve goals

no, you said you clone objects

very different, one wraps an object leaving it intact, the other changes the object at a fundamental level

hold on

what you described is essentially:

I'm doing exactly what you did except I'm doing it like this

foreach ( array_keys( get_object_vars( $post_object ) ) as $property ) {
	$this->{$property} = $post_object->{$property};
}

$objectB = clone $objectA;
$objectB->permalink = get_permalink( $objectB->ID );

@MichaelEcklund that seems wasteful, just pass things to the original object

It looks cleaner in the code though

public function __get($name) { return $this->post[$name]; }

or something like that

eitherway I don't see how this conveys any performance gains

all it does is avoid passing a bad ID into get_permalink, which is avoidable by checking values first

with your way its like: $post_object = new TomjnPost( $post ); and $post_object->post->ID versus my way like $post_object->ID

which could still be a problem, it just moves the issue to your copying/cloning code

oh I suppose ya I could do it like you just said

@MichaelEcklund thats not true, use __get and __set magic methods to pass them along

magic methods meaning PHP provides that in every class? I don't have to define those?

you should read up on them

ya apparently

secure.php.net/manual/en/…

but tbh I'd just use the native API calls

well I mean I am still using the native API calls

just one time instead of 50 thousand times

there's no performance difference

it's not about that really

you might ave a few nanoseconds doing it

it's about shorter and cleaner looking code

by spending just as many nanoseconds on the new overhead of the classes

imo it's just introducing complexity

and increasing memory usage

so with my way, I can refer to the featured image simply just like: $post_object->featured_image instead of $featured_image = get_post( absint( get_post_thumbnail_id( absint( $post->ID ) ) ) );

so much easier to read and understand what's going on

I mean that's probably a bad example, but you get the idea

or like for post_author ... I have it set the user object to that property, instead of just the user ID. so I can do $post_object->post_author->ID; or $post_object->post_author->display_name

same with post types... $post_object->post_type->name; or $post_object->post_type->labels->singular_name;

it just makes things faster and easier for me

I like doing it this way

and way less chances of error fetching the data needed because I have classes setup to conditionally retrieve and append the needed data.

it's structured and consistent

I like the idea about magic methods though

that's a lot of absint calls

and I'd use temporary variables, and the 1 action per line rule

if an error occurs in any of those calls it'll show as the 1 line and it'll be harder to debug

there's also the rule that says you shouldn't do more than one -> in a single statement

but yes even magic methods should be considered one of those sometimes necessary evils rather than a nice to have

but additionally, your example has no error checking

$thumbnail_id = get_post_thumbnail_id( $post->ID );
if ( !empty( $thumbnail_id ) ) {
	$thumb_attachment = get_post( $thumbnail_id );
}

Versus just $post_object->featured_image;

that doesn't give you much info though

and you still have to perform a check to see if it's set or an error message

and you don't know at which stage it error'd

whereas all the featured post functions also take a WP_Post object

so you could easily call get_the_post_thumbnail( $post_object )

and what if you wanted to throw an attribute on the thumbnail in widget, but not in the main listing

you're now stuck because you cached it earlier

ideally, you'd want to shield all those member variables from the outside world

and expose a method based interface

so really it should be something like $obj->get_featured_image_tag()

which internally calls the WP APIs

whereas right now you're doing 2 things, caching, and trying to simplify the interface for your own purposes

once you've moved to methods, you can make the new object extend an interface and genericise it

for example, I wrote an object that saved me writing raw SQLite queries on a table for a CLI tool

I encapsulated everything, so outside code couldn't see the internal implementation details, and didn't need to know

then I extracted an interface

and implemented a version of the class that uses WPDB

but the code that uses it only type hints on the interface

later on I realised they shared some code, and implemented an abstract class that implemented half the methods

in your case, WP takes care of caching already internally

so it's just helper methods and helpers essentially

My plugin successfully adds the rewrite rule, but it only gets used if I manually turn on pretty permalinks, which I don't want to require.

This is a plugin for internal use, so I'm not concerned about forcing pretty permalinks to be on.

so you want your rewrite rules to work even with pretty permalinks off?

@TomJNowell Either that, or I want to turn them on from the plugin. Either is viable for me since this is a plugin for a single website.

I don't think the first is possible

since it's for a single website, why not just turn pretty permalinks on?

That'd probably be fine, I'd just like to make as difficult to break the website as I can.

in that case asking how to force pretty permalinks on would work as a main site question

or, making it super nag the user to turn them on

Ok, thanks, maybe I'll go ahead and ask :)