Support

Search results for ""

Sorry, no results found. Perhaps you would like to search the documentation?
All Topics
Philippe

Polylang integration

Maybe I did something wrong, but when I turned on Polylang integration for a new Custom Post Type, I was unable to get Admin Columns Pro to display all the language/translation Columns – I never got more than 2 out of 3 languages to display at the same time.
So maybe a checkbox “Polylang” somewhere in ACP might be quite helpful.

4 years, 4 months ago
Philippe

Ah, “Restore columns” did the trick.
So, probably no need for the aforementioned checkbox, but maybe a hint somewhere in the documentation?

4 years, 4 months ago
Stefan
Developer

Hi Philippe,

Thanks for the feedback. I will try to reproduce this issue and see if we want to build in any support for this.

4 years, 3 months ago
alex7

Hello Stefan,

Any news on this issue ? I get the same problem. It will be great for AdminColumns to handle Polylang columns :)

2 years, 4 months ago
Tom Bruyneel

Same issue here, after enabling admin columns on a custom type (PODS) the polylang columns don’t work as expected.

2 years, 4 months ago
Stefan
Developer

Hi All,

There is not really a ‘fix’ for this, just a workaround.
The problem is that our plugin needs to save the column state of all default columns loaded and managed by admin columns. This means that dynamic columns like Polylang, do not work in combination with our column management.
You could create a new column set and let it behave as a default overview (so without the interference of our plugin).
To do that you can follow these steps.

1) Create a new column set and give it a name that implies that you’re working with the default overview (or for Polylang purposes)
2) For the new column set, click on the ‘restore columns’ link on the right of the settings screen. This will reset the column set to the default settings
3) The most important step is not to save the column set

This overview should exactly work as Polylang intended.

2 years, 4 months ago
Kenneth

Stefan:
I’d like a clarification on this work-around. I run Admin Columns Pro with Polylang (two languages) in a Multisite environment. Using your workaround I was able to create a new Column Set that in fact has the default functionality you describe. Here’s what’s unusual. On one of my multi-sites I have a POSTS list (this problem apparently exists with both Posts and CPT’s) that contains an “Original” column-set that contains both language flags and functions as anticipated, including having all the Admin Columns with inline editing and new column sets available. Apparently, I have not attempted to add any new columns under this “Original” column set and apparently haven’t hit the Save button either. Am I correct in assuming that this is how both flag columns remain functional in this column set even though it contains many new columns with full functionality under Admin Columns? If so, I am assuming that this issue began after Column Set functionality was added in a prior version of Admin Columns. If so, would we be able to install a prior version of Admin Columns, add columns as desired, then upgrade making sure never to Save that modified Original set. Would we then be able to retain a single Original column set with full functionality, including added columns with inline editing, and retain all language flags in that set alone?

2 years, 4 months ago
Guillaume

Polylang integration is not solved yet.

Polylang definitely doesn’t work with Admin Columns Pro, contrary to what is written in Polylang 2.4 version notes (be careful if you buy it): when we customize columns, the flags column disapear.

Asked to Polylang and Admin Column support, but they accuse each other and nothing change.
Polylang support doesn’t even answer my requests anymore.

Too bad, great plugins, but separately.

7 months, 2 weeks ago
Philippe

@Guillaume Does the « create new column set » workaround not help? It certainly is not very elegant, but better than nothing, I guess. I used it on a WPML site where the language flags kept stubbornly vanishing, and so far I think it worked.

7 months, 2 weeks ago
Robbert Stapel

Sadly, this is still an issue…

I removed Admin Columns, deleted the remaining table via WP-Optimize and then reinstalled Admin Columns. Issue solved. This seems like a cleaner work-around because you don’t need to overwrite any defaults. You have to save and re-import your column settings if you already have something up and running…

Making a custom column, copying the code from the polylang plugin can be a work-around to use your custom columns together with Polylang.

This topic should have more attention in my opinion!

3 months, 1 week ago
Stefan
Developer

The workaround of creating a column set and store the column settings without saving (means you want to load the default columns by WordPress or plugins that use hooks) is the only way at this moment.

Let me give you a better understanding of the issue. Our plugin allows you to manage columns and save those settings as a persistent set, allowing you to remove columns that would normally be added by WordPress or other columns. In order to do our magic, we have to use a high priority hook to make sure that all earlier set columns are overwritten with our persistent one.

Polylang uses dynamic columns based on the context (language) you’re on. So for the same overview, they can add multiple columns based on a param in the URL. Since they use a lower priority than our hook, the columns are directly overwritten with the stored admin columns. If you’re on the English language overview and go to our settings page, you’re be able to add the other languages and even store them, but when you switch to another language, the stored language columns are probably gone, because they are not available anymore in the default set.

It is possible to add the Polylang language columns on a higher priority than our plugin (our priority is 200, so use a higher number). In that case, it will overwrite the columns that are set with our plugin. It will also cause that the language columns are always available on every column set with our plugin not being able to remove them.

This is the only workaround I can think of, simply because dynamic columns and persistent columns are two different concepts that do not work great together.

3 months, 1 week ago

You must be logged in to reply to this topic.