TODOs from readme.txt about autoshare-for-twitter HOT 9 CLOSED

@dinhtungdu At an earlier stage the Composer dependencies were committed to the repo. Now that we have a build and deploy process and are .gitignoring the vendor directory, I think that one is complete.

This plugin's Twitter integration is simple enough that the dependency (a pretty large package) could be fairly easily removed in favor of a simple API abstraction. Maybe that would be worth considering at a future stage.

Regarding jQuery, I agree there might be no need to spend time on that. The jQuery-dependent script only loads where the classic editor is being used, so it will always run where jQuery is available in the environment. The 5.0+ script doesn't use jQuery.

from autoshare-for-twitter.

@iamdharmesh Sound promising to me, can you work on a PR?

from autoshare-for-twitter.

@adamsilverstein leaving the checklist TODO items above for you to validate whether they're done or not and if not if they need to be split into their own issues to milestone in various releases.

from autoshare-for-twitter.

@jeffpaul Can you clarify this for me:

Remove composer dependencies from the repo

from autoshare-for-twitter.

Remove jQuery dependency

About this, do we really need to remove jQuery? Our plugin is run only in the admin area where jQuery is always loaded. I'm wondering if it worths the effort?

from autoshare-for-twitter.

@jeffpaul @johnwatkins0 for the first item, I'm wondering what is the best UX for it:

We detect local environment, prevent tweets and:

• Do nothing.
• Display a notice says that we don't tweet to Twitter when testing in the local environment.
• Change the text Tweeted on 2020-02-11 @ 2:50AM to something relevant to the localhost context.
• Something I haven't thought about yet...

The first item:

Reevaluate storing the Twitter credentials in the database OR do a environment check. There's potential for a local environment tweeting publicly if using a copy of the production database.

from autoshare-for-twitter.

Just thinking about what I would prefer as an engineer on a client project. Accidentally tweeting to a client's Twitter account from my local environment would be a bad day, so I can see why that note was added.

Perhaps the user could be asked to enter the site URL on the settings page. The label text could say the precise reason -- "Enter your site domain [or site home URL, and we can parse the domain out] to prevent Tweets from being sent in test environments."

from autoshare-for-twitter.

@dinhtungdu @johnwatkins0 I agree that we should find a way to try and prevent those sorts of accidental tweets. I'm curious what other plugins might have similar "prevent functionality from non-production environments" concerns to see how they're handling those scenarios. Any thoughts for plugins with similar concerns that we may be able to learn from?

from autoshare-for-twitter.

@dinhtungdu @jeffpaul We may get a reference from "WooCommerce Subscriptions" or JetPack Safe Mode.

I had checked on Woo Subscriptions earlier, it saves the site URL in the options table by inserting a key into the middle of the site URL(https://example.com will be saved as https://ex_[autoshare_siteurl]_ample.com) to prevent it by getting replaced during migrations. So, when the plugin detects a new site URL it shows the notice with actions for staging env and stops the automatic subscriptions, for our case we can stop tweet functionality.

Please let me know your thoughts on this.

Thanks.

from autoshare-for-twitter.