Adriano Monecchi

Hey, thanks for your reply. Somehow the uploadcare plugin’s settings were being cached on admin backend after the plugin update. After inspecting it further, I cleared the browser cache and the new option was there.

It is resolved now, as unchecking the option “Download images to server from Uploadcare before publish” brings back the direct link to uploadcare’s cdn.

Still waiting…

So pity but it seems the plugin’s support is dead ?? – Almost all support threads have nos answers at all.

I think I might have found why I’m facing such an issue after all. It seems that the plugin defines a $url variable on oauth1-authorize.php line 10, assuming wp-login.php is accessible.

So the following would not work on my theme as mentioned on the first thread:

$url = site_url( 'wp-login.php?action=oauth1_authorize', 'login_post' );

wp-login.php is not accessible on my theme.

Hey @achernenko, thanks for following up! I’ve got the latested version installed. Actually I forgot to mention I was trying to get the widget localized on the Admin side. In the frontend it works as expected though.

Uploadcare’s plugin is awesome, but the widget’s customization options in the backend is quite limited. I was hoping to be able to apply the same features in the admin, as I’m able to on Uploadcare’s widget configuration page.

I’m quite sure the plugin will get improved in the near future, but when it comes to writing code the WordPress way, it seems to be lacking the methods in order allow users to extend its functionalities. I mean, there are a few functions which would run perfectly trough the apply_filter() one, allowing users to change things like the widget’s tabs and effects on a per page/logic basis.

It’d be great to have a few more settings for applying features that in some way extends the widget, then let those settings be changed by providing some useful filters. As an example, I prefer using gphotos (not available in the settings yet) instead of gdrive, so I had to edit the plugin’s files directly, if there was a filter, although having the settings is essential, I could have easily changed that with a few lines of code.

I also have a feedback regarding the “Download images to server from Uploadcare before publish” option, which is great by the way for those willing to save some disk space, but it’d be awesome to have an additional option to keep both versions of an uploaded image in the media libray. I mean, I’d rather keep both versions, the local one and the uploadcare’s one, just in case in the future I decided not to use Uploadcare’s services anymore. That would certainly allow users to easily switch their post’s images to the ones locally hosted in the media library.

Anyway, I should thank you guys for bringing up such a great service Uploadcare provides. I’ll keep watching the plugin’s for future updates and improvements.

Regards,

Adriano.

Hello @ninjew. Thanks for the follow up.

I’ve tested the plugin’s latest version 3.1 with WordPress 3.9.7 – 3.9.8 on both ( php 5.6 – 7.0 ). I’ve debugged it as far as I could but the issue persists. Unfortunately, I’ve uninstalled the plugin as that is a huge drawback.

Hi there. I’ve just noticed a new update was released – However, after installing GEO My WP 3.0.2 I still can’t see any of the plugin’s js files enqueued in the frontend.

I’ve re-checked the plugin’s settings and the Current Locator Addon is enable and proper configured. Also, all the other Core Extensions addons are activated. I’ve even tried to clear my browser’s full cache and the settings for my site, but the issue still persists — only the plugin’s css files are being enqueued.

I’ll be deactivating the plugin for now, but I’ll keep watching for its progress.

Thanks in advance.

Sure. Indeed the Single Locator core extension is activated. I’ve uninstalled/installed the plugin again and erased all data, but the issue still persists.

Sure. Indeed the Single Locator core extension is activated. I’ve uninstalled/installed the plugin again and erased all data, but the issue still persists.

Boa ideia. Seria legal se o plugin tivesse um repositório no Github. Estou testando o plugin e fiz algumas altera??es no código. No Githib ficaria mais fácil receber contribui??es, o que acha?

I’m thinking about using your plugin, it looks promising! I also do need to override the payment methods within the select dropdown field. It′s not wise to override the plugin’s files directly though. Your plugin should have the payment methods wrapped with the apply_filters()function, that way users would be able to change it safely.

Pensanso em usar o plugin, parece bacana. Eu também precisava adicionar meios de pagamento específicos no select. O ideal seria o seu plugin usar a fun??o apply_filters()e permitir que o usuário substituisse os meios de pagamento usando o filter hook do plugin.

Tava bacana essa funcionalidade no plugin ?? é complicado manter essa funcionalidade no mesmo? E quem n?o utiliza os servi?os de entrega dos Correios? Essa funcionalidade é muito importante e penso que ter que instalar o plugin Correios WooCommerce pra ter apenas essa funcionalidade fica meio puxado…

Eu até implementei um esquema de auto preenchimento do endere?o no checkout com a API do Google, mas a sugest?o de ceps que o Google faz nem sempre é confiável, e pode induzir o cliente a processar dados incorretos, por isso, colocar em destaque o campo do cep logo acima dos outros campos do endere?o e tendo o apoio da fun??o de auto preenchimento pelo cep estava sendo a jogada perfeita!

Bom, mas é isso né, se n?o fosse a imensa colabora??o aí do Claudio e de outros desenvolvedores n?o teríamos tanta coisa bacana pro WordPress! E quem já é “casado” com o WordPress sabe que dá pra ficar louco com tantas atualiza??es de plugins e do próprio WP, mas esse é o mundo web, em constante transforma??o…

Triste notícia mas vamos seguindo ??

Obrigado pelo retorno. De fato o problema n?o é originado pelo plugin!

Consegui resolver pois identifiquei que havia um float: right; na página de checkout adicionado pelo css do tema, e que de alguma forma só causava essa interferência nos campos do formulário de checkout se o plugin estivesse ativado.

Removendo a classe css resolveu tudo!

Obrigado pelo plugin! é Perfeito!

Hey there @kyawthein!

Have you updated to WooCommerce 3.0 yet? – Me not! I was getting this type of error along with some other issues and I’ve managed to fix it by making a few changes to the plugin’s class.yith-wcwl-shortcode.php file.

See also: https://www.ads-software.com/support/topic/shortcode-non-funziona/

This is not an update proof method, but that fixed the error for me while I wait for my theme’s developer to come up with a fix on their side.

Chiao Kiarma. I was facing the same issue as you with Yith Wishlist plugin while still running WooCommerce 2.6.14 (I haven’t updated to WooCommerce version 3.0) yet.

It seems that the way the plugin gets the product ID is causing a lot of issues, and completely breaks my theme’s current integration when using the Yith’s shortcode as such <?php echo do_shortcode('[yith_wcwl_add_to_wishlist]'); ?>

I’ve came up with a “Hard Fix” by modifying the plugin’s class.yith-wcwl-shortcode.php file directly, so this is not update proof.

You might want to give it a try and see if that works for you, but don’t forget to make a backup of the original file first before overriding it. I’ve commented the lines where I’ve performed the changed with the word “fix”, do a search in the file contents and you’ll be able to see what changes were applied.

You can grab the modified file here: https://gist.github.com/monecchi/3dbb0d2265d4714b159eca6ae3e8a8dd

Apresto and Good Luck!

• This reply was modified 7 years, 10 months ago by Adriano Monecchi.