EkoJR

A new update is available. Updating should resolve the issue.

The last version prior to WPML support was 0.3.7.

1. At WP.org Plugin Page, go to Advanced View.
2. Towards the bottom, there will be a ‘Previous Versions’.
3. Select ‘0.3.7’ from the dropdown, and click download.

Understand the need to have certain functionality, and will try to notify you when additional settings have been put into place for that type of effect.

That is awesome to hear! I use the plug as a core part of majority of my projects, and always found it interesting how it’s helped others.

I haven’t began pushing for reviews, but a recent update brought a lot in, and giving APL a high rating would help others on WordPress. If its saved you time, energy, and possibly even resources, then maybe consider supporting APL as well.

Your issue may not be a post-effect ( continuous affect ).

1. Go to Edit Post List.
2. Enable ‘Empty Message’, and add some form of placeholder.
3. Go to the site location where the Post List is being rendered.

A. If you see your placeholder, then that is good.
B. If you still see nothing, then there is a problem.

If you end with B, then there is a known issue with the slug itself.

That’s quite a bit, and thank you for explaining.

Yes, it is possible to revert back to the old version, but I believe what you had mentioned is an intended concept.

Now it′s all messed up, the only way to display the danish language shortcode is to have the danish flag selected (in the black top bar – not the Edit Translation part of the plugin ) then open Adv. Post List, and select the the danish list name e.g [post_list name=’rodan-list-products-h1-dk’] – save the settings and then it shows.

This is an intended effect to be more compatible with WPML, which is being manipulated by WPML’s pre-query, and WPML does have a method to query other languages, but I think I may have to add additional settings for individual post lists as well.

• This reply was modified 7 years ago by EkoJR. Reason: Correction

That might be a key clue.

It is suppose to set the post type when it is set, including any/all. I’ll have to run some tests and find out why it isn’t picking up that up during the upgrade.

The Any/All is a default setting for both the Post Type, and Taxonomy, but the post type simply just needs to be active. I did notice a bug when editing, it will set a different default (1 active taxonomy), but the database has it set to any. It was a bug I noticed later that I was hoping wouldn’t see too much use, but I will have to correct the UX in JavaScript.

Settings page def should not be showing up blank. Something might be conflicting if that is happening.

I believe it could be an issue with fetching the design to render.

1. Go to Edit Post List.
2. Enable ‘Empty Message’, and add some form of placeholder.
3. Go to the site location where the Post List is being rendered.

A. If you see your placeholder, then that is good.
B. If you still see nothing, then there is a problem.

With the way WP functions with edit post data, the preview concept was defunct, but the customizer functionality would be a possibility.

Eeek…ouch :/

That was a focus to try to take extra measures on. Particularly with the case of server migration where IDs don’t always match up. I am curious what might of kept the terms from matching up though.

The plugin did undergo a lot of work to try and bring in some much needed changes, and one of them was a database conversion, but the biggest upgrade is getting rid of that old layout for the settings page. All in all, there were many other improvements. Ended up being one of the biggest changelogs, and was about 4 months.

Hoping it benefits a lot of people though, but still encourage others to report any issues. As it helps to identify and bring in the necessary changes.

Glad you stayed with v0.4.1 ??

It’s basically using the parent/main post list. Instead of using WPML Manage by clicking on ‘Edit Translation(s) of this Design’ at the bottom of the Display Settings. Just use the Display settings as is.

Translations would still be hindered, but it shouldn’t defunct it. The query should work with multiple languages, but the design is stuck with the parent until a fix can be added.

One of the things I love about APL is the encapsulation, but it also makes it very hard to find lol.

It looks like the Design data used for rendering isn’t loading, and it looks like a bug, but it’s hard to tell if it could be a conflict in particular.

The only solution I can think of until this is completely resolved, is to use only the parent design. No WPML edits to post lists. Unfortunately, you will have to use 1 language, but I think it is possible to still query posts of different languages.

It is possible you found a defect/bug. WPML is a fairly new addition, but I remember working on a similar issue in the past.

However, there is one other recent issue that does have a troubleshoot. If a Post List slug is similar to any other slug in any post type, and a plugin is hooking into pre_get_posts. Then changing the Post List Slug to a unique name may solve the issue. Altho, you should not need to change each language slug…just the post list.

Your case seems to be different, and similar to a past issue I remember. So in that regards…

* The language that is not working, is that the base language for the site?
* Are you displaying languages based on the subdomain?
* You mention shortcodes not working. Are you referring to ‘Internal Shortcodes’, or the post_list shortcode?
* If ‘Internal Shortcode’ is suspected, are you able to confirm other parts of the design being rendered, but does NOT show any data from the ‘internal shortcodes’? For example, if you save [post_title] Foobar you would seefoobar.

WPML Support was released slightly early. Since the next release (v0.5) already had plans to enhance the rendering capabilities and refine the functionality on the admin side, BUT with the changes in v0.4…it would be a lot easier for others if WPML was added now, and then work out the kinks anyways.

• This reply was modified 7 years ago by EkoJR.

Possible Solution: Change the slug to a unique value. By that, I mean a slug that is completely different from any other slug on the website.

I found a possible bug that was resolved once before, but it seems to be triggered environmentally when certain plugins/themes are in use.

Yes and no…this is a method that still allows old bad habits, which occasionally become restricted, especially with security & performance plugins.

I’ve thought about adding a workaround setting, but keeping the -1 setting is already frowned upon.

Even though you would prefer no limit, the best suggestion option would probably be a large number for the list amount. I believe it is an Int variable type, so try not to exceed 2,000,000,000.

If there was additional information supplied regarding certain configurations, then I could expedite an update for everyone. Unfortunately, very little to no information has been supplied.

For anyone that might have the same issue, and would like to help. There is a Development Form available to initiate a private discussion.

Right now, I’m looking into…
* Plugins that may use pre_get_posts.
* A possible defect in the Updater Class. (Altho, it doesn’t appear to be the root issue)