Inmo

You can achieve this by using info from the $_GET array. However you do need to accommodate two situations in your IF clause, one for the new screen (creating a fresh post) and one for the edit screen (an already saved post).

On a new post/page screen you can get the post type via… $_GET[‘post_type’]

Once that post/page has been saved, you will instead need to use… get_post_type($_GET[‘post’])

Just wrap your css file enqueue function in side the following…

if ($_GET[‘post_type’] == ‘page’ || get_post_type($_GET[‘post’]) == ‘page’) {
}

Hi Guys,

Thank you Mert for the plug-in, it’s enormously useful and a great idea.

I found a manual work around for the problem in the end although I am working on a client site that is littered with a long list of random plug-ins, I don’t think any of them are creating db tables of their own. I’m not massively experienced with SQL stuff in general but when I log into phpMyAdmin I can see there is only the standard 11 tables that WP creates on installation.

When I was trying to figure out a workaround I did notice that the backup .sql file that had been transmitted to the new installation was very slightly smaller than the same file on the original server where it had been generated by the plugin. On seeing this I simply used ftp to manually grab that one single .sql file from the original installation and overwrite the received version on the new installation. Once I’d done that, the updated (now matching) file size was reflected in the ‘completing migration’ page and I could check just that file and complete the migration process with no further issues.

I hope that’s in some way useful.

I just came up against this same issue and have used the following fix.

PLEASE NOTE: This involves a very simple edit to the plugin file itself ‘video-poster.php’ which means that should you update the plugin in future then this change will be overwritten and you’ll have to redo it. I’m not sure that’s a big issue in this scenario as the plugin has not been updated in almost and no longer appears to have an author page outside of www.remarpro.com but I thought I’d mention it upfront in case you are working on a client site and you don’t want to risk the possibility of them overwriting it with an update in future. Maybe there is someone out there who can suggest a way to implement the same change outside of the plugin file but that’s a little beyond me right now …phew, boring bit over – onto the fix.

So open up video-poster.php in the Simple Video Embedder plugin folder and scroll down to line 143 where you will find the follow function…

add_meta_box("p75-video-posting", "Post Video Options", "p75_videoPosting", "post", "advanced");

this is responsible for adding the various video related fields to your post admin screen. The 5th argument passed to the function (“post”) is the part that dictates which post-type you are adding this too. So if you want also add the videos to your pages too, then you just need to make a new line below and duplicate this whole function there and edit the “post” argument on this new line to “page” instead…

add_meta_box("p75-video-posting", "Post Video Options", "p75_videoPosting", "post", "advanced");
add_meta_box("p75-video-posting", "Post Video Options", "p75_videoPosting", "page", "advanced");

make sure all of this is still inside the curly brackets belonging to the ‘if( function_exists(“add_meta_box”) )’ statement above.

I haven’t checked this personally but if you want to add the functionality to a custom post-type then it should just be a case of creating a new line with the same code above and substituting “post” for the name of your custom post-type instead.

Hope that all makes sense.

I am having this same issue. Did you ever find out the cause of the problem?

Thank you ??

Jeff, what you’re saying really should work but for some reason I can’t get ‘order’ to have any effect. Do you have it working for you?

I came up against this same situation today I think.

First thing to do is to add the the following parameter to the $args array that you are passing to get_posts()…

‘orderby’ => ‘menu_order’

This will sort the returned array of attachments in relation to the gallery order you’re requesting (if I’ve understood correctly).

However, when you do the above you’ll notice that the results are actually output in descending gallery order which is the inverse of how they are presented in the gallery admin panel. To rectify this and make everything nice and user friendly you just need to reverse the get_posts() array that’s returned, before you pass it through the foreach construct.

So to take your example…

https://pastebin.com/cJCGAt6e

I came up against this same situation today I think.

First thing to do is to add the the following parameter to the $args array that you are passing to get_posts()…

‘orderby’ => ‘menu_order’

This will sort the returned array of attachments in relation to the gallery order you’re requesting (if I’ve understood correctly).

However, when you do the above you’ll notice that the results are actually output in descending gallery order which is the inverse of how they are presented in the gallery admin panel. To rectify this and make everything nice and user friendly you just need to reverse the get_posts() array that’s returned, before you pass it through the foreach construct.

So to take your example…

https://pastebin.com/cJCGAt6e