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.
Ah, “Restore columns” did the trick.
So, probably no need for the aforementioned checkbox, but maybe a hint somewhere in the documentation?
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.
Hello Stefan,
Any news on this issue ? I get the same problem. It will be great for AdminColumns to handle Polylang columns :)
Same issue here, after enabling admin columns on a custom type (PODS) the polylang columns don’t work as expected.
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.
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?
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.
@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.
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!
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.
We create specific support for Polylange language columns in Admin Columns Pro 5.6.
It is now possible to add the column type ‘Polylang Language’ to the list of columns.
This column acts as a placeholder and will place all the available flag columns on the given position.
When this column is not present on the columns set, no language column will be displayed at all.
This new Polylang language column is really nice and very helpful, thanks!
I noticed there’s no polylang column available for any taxonomy. Is that by design?
There is indeed no specific column for the Taxonomy page.
I’ve added your request to our feature request backlog.
This request is patched for the upcoming version of Admin Columns Pro.
In the meantime, you could make a small change to the current codebase to make it work.
File: admin-columns-pro/classes/ThirdParty/Polylang/Addon.php
Change the content of that file with the contents of this gist:
https://gist.github.com/DGStefan/292ff7a8a657dffb114bc8a43a16ced2
Hi Stefan,
works like a charm, thanks a lot!
I would like to replace language flags with two-letter language codes. This will be more accessible for two blind WordPress developers that I work with. We are up to 7 languages for our website, soon to add more.
Do I need to start another thread?
Our plugin does not add specific columns for the Polylang plugin, it just uses the default columns for Polylang itself. Your request is more Polylang-related than Admin Columns I guess.
First. I’m using AdminColumns Pro on Multisite install and on Admin Plugins Page shows I have the CURRENT version of 6.3.5 yet Downloads page of your portal shows a version 6.4 and 6.4.1. What gives? Why is WordPress not picking up the two new versions for auto-update? I’m also using Toolset (Types).
Second. When you click the Primary or Secondary language buttons in the top Admin Menu for Polylang it shows all languages in the Admin List for the taxonomy. Also the dialogue box for editing or adding a taxonomy no longer has ANY language-relevant fields as it used to.
Finally, in a post, custom post type or page admin list with a taxonomy column in the list when clicking in the field ALL language taxonomy terms (along with the term #) are being populated for choice even when only the Primary or Secondary language is chosen from the top menu. This is all contrary to the way it has always functioned previously. What’s up and/or what am I doing wrong?
@Kenneth
1) We’re releasing our latest released segmented and not to our full customer base immediately. You can download the latest version from the portal and install the update manually, but it should also be available right now to update to 6.4.1.
2) It is good to know that the main feature of our plugin is to perist the table with columns of your choice. Once you decide which column you would like to see and save the column set, that will be the new column set that will be displayed.
Some columns will add dynamic columns on the fly, like Polylang does based on the language. This kind of logic conflicts with our way of persisting the columns on the page. One workaround to show dynamic columns, is to create a column set that does not have any columns stored. You can restore the columns by clicking the link on the right ‘restore columns’. When you visit the page without any persisted columns, you will see all the columns that would be there without our plugin installed.
For Polylang we also wrote a small workaround with a column called ‘Polylang Language’. This speicif column, should allow Polylang to display the language columns that are normally there without our plugin active.
This is the only fix/workaround we have in place for Polylang but we have not further custom logic for Polylang whatsoever. If the Language column does not work, you could try my first workaround by creating a column set that just loads the default WordPress columns.
Hey. Looks as if the problem was related specifically to conflict in Languages between Polylang and plug-in Advanced Ads as the problem persists even in the taxonomies meta-boxes inside a post edit thus not likely an Admin Columns issue. Once I assure the language feature is working correctly I will confirm that columns are working correctly. Sorry about that.
You must be logged in to reply to this topic.