Ditto Dito

One plugin that comes to my mind has the checkbox in the general settings, un-checked by default, with a text like “Should data be deleted upon uninstall”.

Another has a button “Delete data and uninstall”, separate from the standard uninstall link in WP.

I guess there are more possible solutions.

Thanks for your consideration.

Thanks for your reply.

Yes, it may be common behaviour to leave data behind. That is “common behavior to unnecessarily bloat the database”.

Good behavior is to offer a checkbox somewhere to leave the choice.

This is AWESOME !!

I have searched for a solution without hacking the code, but the obvious hid well.

Thanks a ton, I guess there are still things to discover.

What I meant is that I can publish as expected. And when switching photos, it *looks* as if everything works in the dialogue, but it doesn’t.

I don’t have any caches, other than the browser cache (of which I took care). This is all internal with an Ubuntu LAMP stack hosting WordPress and my Win10 machine right next to it.

And I tried it again, this time documenting everything with screen-captures between the different steps. And it works this time. What a mess.

I’ll keep an eye on this. I do need the functionality, and I am sure there is a problem somewhere.

But case closed for the moment. Thanks a lot for your help!

Hi Jordy,

No, luck.

I right-clicked on an already published image and “Show in Folder”, then selected another photo (unpublished, of course). Although the dialog displays as if everything went fine, there is no visible change: The “published” collection in WP/LR still shows the old photo, not the new one. And on WP there still is only the old one.

There is no error message in the log-file. Not on the PC, not on the server.

I see that some of the “new” images I have been playing with are in WP/LRs general “Photos” folder (not in the collection I am using for publishing). I published them, but although everything seems to be fine, they don’t arrive on WP.

Very strange, all this.

I will clean up everything and start from scratch to see.

Edit : Did so, nothing works here. This is what I did :
– select three photos and dragged into the standard Photos folder of the WP/LR publishing service
– published
– they arrive in the WP media library ; they are in the Published section of WP/RL
– go to Folder of one of the photos
– select arbitrarily another photo
– Switch photos – all seems to be correct and running w/o problems.
– nothing changed nowhere

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

That you can do already with the File Naming, right? File naming is handled by LR but you can customize it. I guess that works the way you want (I am basically using the same pattern).

Dang! File Naming doesn’t offer me to select Collection Name, just Folder Name, and that’s the folder on my hard drive. Bad surprise of something that seemed obviously very useful.

Is this something you could possibly fix in the LR plugin ?

Hello Jordy!

Thanks for your reply! My best idea for the moment is to play around, and probably try to write a plugin to handle the image replacement part.

Will report how it goes.

@jerepowers : You can get rid of the bullet points with a little bit of CSS :

ul.nooz-list {
list-style: none;
padding-left: 0;
}

So it turns out that a single comma added to plugins/nooz/inc/shortcode.php solves this problem.

function mdnooz_shortcode_posts_groupby( $sql = '' ) {
    global $wpdb;
    return $sql . ($sql ? "," : "") . "{$wpdb->posts}.ID";
}

With this hack (fix?), Nooz articles show up in the currently active language.

This needs more testing (especially since I am only using “coverage” articles so far), but it looks as if the data management (admin side) and data delivery into the front-end works.

With the above I can manage the different language versions for Nooz types in the backend.

Calling the frontend Nooz shortcode gives no results. Further inspection shows that get_list_shortcode_data() in NoozCore.php creates a faulty SQL statement:

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts
            INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id)
            LEFT JOIN wp_postmeta AS mdnooz_postmeta ON wp_posts.ID = mdnooz_postmeta.post_id AND mdnooz_postmeta.meta_key = '_mdnooz_post_priority'
                WHERE 1=1
                AND (wp_term_relationships.term_taxonomy_id IN (4))
                AND wp_posts.post_type = 'nooz_coverage'
                AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')
                GROUP BY wp_posts.IDwp_posts.ID
                ORDER BY mdnooz_postmeta.meta_value DESC, wp_posts.menu_order DESC, wp_posts.post_date DESC
                LIMIT 0, 5

The GROUP BY is obviously not good. Throwing out the secont wp_posts.ID gives the following MySql-Error:
#1055 - Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'vucms.mdnooz_postmeta.meta_value' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

Adding mdnooz_postmeta.meta_value to the GROUP BY gives the expected results, so there is some light at the horizon.

First thing to solve was to make Polylang accept the two Nooz custom post types. Well, currently two, there are maybe more to come. To avoid surprises, I asked the Nooz core which CPTs it handles and then tell Polylang about it in my functions.php

// add Nooz CPT to Polylang
add_filter('pll_get_post_types', 'my_pll_add_post_types');
function my_pll_add_post_types($types) {
    $nooz = mdnooz(); // get Nooz's CPTs
    return array_merge($types, $nooz->get_post_types());
}

Without this filter, Polylang already somehow recognized Nooz. It showed “Press Release” in it’s translatable CPT, but not “Press Coverage”. Strange thing is that I had no Press Release but 1 Press Coverage as I tested this. So as worst case, PC should have been recognised, not PR. But be it.

Thanks! See you on GitHub

@farinspace, good arguments. I can agree to them.

I am set with your solution. I initially serialized() the $data and shoved it over into a page template. Not quite as elegant as your suggestion.

Thanks for your support. Good stuff!

Nice! Much better than what I came up with. Thanks!

Thanks, niknetniko.

Well, the plugin says that it uses the new NextGen api. So I guess the main question is how much they differ.

I’ll have a closer look myself when I find some time. I’ll probably come back with more precise questions. Thanks anyway !