Ruud Laan

Thanks Ryan,

Much appreciated.

Hi Ryan,

Thanks for your feedback.

>Thanks for your assistance ??
No worries, glad to help out.

Please let us know once you have a new version out with a fix.

Thanks,
Ruud

Hi Ryan,
I had some time to dig a little further into this bug.

I think I found the source for this bug. In the plugins legacy.php file an action is used to create a taxonomymeta table in the wpdb object.

Then from the call in the theme the attachment ID is retrieved which triggers update_meta_cache(). update_meta_cache then tries to attempt to locate the proper table, it tries ‘taxonomymeta’ and because action just added this table it doesn’t return true. Next update_meta_cache tries to do the SELECT taxonomy_id, meta_key, meta_value FROM wp_ceia_taxonomymeta query, which fails.

I’m not sure what to make of this, I haven’t seen the error reappear also.

Please comment.

Thanks,
Ruud

Hi Ryan,

No that plugin is not in use. I saw some references to that one also, that got me on track to this plugin. However it seems it must be something else, I will try to debug this error later.
Thanks for the feedback, I’ll close this topic for you.

Thanks,
Ruud

Thanks, would appreciate that.

I pushed the changed file to the server for now.
Are your releasing an intermediate version, like 4.6.1?

Hoi Manny,

I tried your fix, and the newly uploaded file is visible and selected after upload.

Thanks,
Ruud

Hi Manny,
Thanks for your quick reply.

I’m not sure that being able to remove images from the modals’-collection pane is needed. But pre-selecting the file uploaded is the default action of the modal in the 4.5.7 version which is excellent.
How would it work if you upload files simultaneously? select none, select all?

Thanks,
Ruud

Hi Manny and Jon,

I just ran into the same problem.
I’ve downgraded to version 4.5.7 which is still working as normal.

Normally the media select modal shows the file being uploaded at the main collection of images, but not anymore version 4.6.0.
After some switching around is does appear like Jon says.

Thanks!
Ruud

Interesting; not sure how this plays well with the option to enter a external URL.
Look into it though, maybe we can incorporate this into a new version.
Thanks Viktor!

Hi Viktor,

Thanks for this tip. I looked into this option. Do you mean something like leveraging wp_link_dialog() and a usage like: https://stackoverflow.com/questions/11812929/use-wordpress-link-insert-dialog-in-metabox ?

If so: that will insert a complete url, where as we are storing a post ID.
Via this ID we later retrieve the permalink. This will ensure no internal links will become dead links even if a post slug changes.

The dialog does add a search function, which would be useful. The upcoming ‘Pro’ version of the plugin does have a settings field for selecting which posttypes to show in the dropdown, to be able to exclude certain types you don’t need.

Thanks!

Hi Viktor,

Thank you for your remark and sorry it took me a while to get back to you, we had a great time at from WCEU, Sofia ??

Your absolutely right: no admin classes/js should be loaded on the front-end. I checked the plugin code for obvious omissions (like not using is_admin(), but will take a closer look with your plugin to see what might be going on to see where we can improve

Thanks for this information!

Hi Shawn,

I can confirm it works for me ??

I think the other parts of the patch you mentioned earlier needs to be applied too. I had a quick look at those and thought they were OK.

Hi Ruson,

Patch is a command-line utility: https://en.wikipedia.org/wiki/Patch_%28Unix%29

I do not use patch from the command line, so I cannot help you with that. You can use this patch by just looking at the code changes it makes in the actual text of the patch (compare the + and – lines). Or you could use a text-editor with patch capabilities. I use Eclipse to this end.

The patch you mentioned does have a minor flaw: the function should return $locale and in the patched version it does not.
I have added a different patch to address the notice you found:

Index: htdocs/wp-content/plugins/qtranslate/qtranslate_hooks.php
===================================================================
— htdocs/wp-content/plugins/qtranslate/qtranslate_hooks.php (revision 823892)
+++ htdocs/wp-content/plugins/qtranslate/qtranslate_hooks.php (working copy)
@@ -48,17 +48,19 @@
global $q_config;
// try to figure out the correct locale
$locale = array();
– $locale[] = $q_config[‘locale’][$q_config[‘language’]].”.utf8″;
– $locale[] = $q_config[‘locale’][$q_config[‘language’]].”@euro”;
– $locale[] = $q_config[‘locale’][$q_config[‘language’]];
– $locale[] = $q_config[‘windows_locale’][$q_config[‘language’]];
– $locale[] = $q_config[‘language’];
–
– // return the correct locale and most importantly set it (wordpress doesn’t, which is bad)
– // only set LC_TIME as everyhing else doesn’t seem to work with windows
– setlocale(LC_TIME, $locale);
–
– return $q_config[‘locale’][$q_config[‘language’]];
+ if ( isset( $q_config[‘language’] ) ) {
+ $locale[] = $q_config[‘locale’][$q_config[‘language’]].”.utf8″;
+ $locale[] = $q_config[‘locale’][$q_config[‘language’]].”@euro”;
+ $locale[] = $q_config[‘locale’][$q_config[‘language’]];
+ $locale[] = $q_config[‘windows_locale’][$q_config[‘language’]];
+ $locale[] = $q_config[‘language’];
+
+ // return the correct locale and most importantly set it (wordpress doesn’t, which is bad)
+ // only set LC_TIME as everyhing else doesn’t seem to work with windows
+ setlocale(LC_TIME, $locale);
+ return $q_config[‘locale’][$q_config[‘language’]];
+ }
+ return $locale;
}

function qtrans_optionFilter($do=’enable’) {