Ok,
So about a year ago (I think) google went through a transition where they made Google Apps accounts "real" so we could use them in places like the Chrome Web Store. Unfortunately, prior to that happening I had written some extensions that were under the now conflicting account. So, now what I've got is a two accounts where the old extensions are under this conflicting account and anything past that date is under the new account.
So, it is time to upgrade some of these (old extensions), what I'd like to do is move the extensions under the apps account in a way that doesn't cause problems for the users. Does anyone know a way? It seems like the only option is just to place the extensions under the new account and delete them under the old account, but then I think all of the users would have to know to install the new one.
Thoughts? Has someone gone through this process?
EDIT: As #artur-nowak pointed out in the comments it is now possible to transfer extensions between accounts using this form.
If only your extensions were hosted outside Chrome Web Store (CWS) it would be possible to solve this by modifying update_url in manifest.json (so that extensions will start to download updates from another source). But they are not, and CWS doesn't allow you to modify the update_url param. Because of that, I believe you have two options left:
wait for google to add 'change ownership' function in CWS
or add your extensions to CWS again as a desired user and update the old ones to display a popup/notification "please update" with a link to the new version. Users should be more eager to update if you include some new features to attract them. Also, it will be less annoying from them if config will be preserved. To achieve this, export settings to bookmarks panel (it will be easy to access them) and import them in the new version of extension when it's installed.
Related
I need support with the usage of Google Docs: I want all the docs every employee in our agency creates be uniform in terms of font and headline settings. We are working with templates in our google workspace, but the default way people open new docs is not the template.
They just open a new doc and it's understandable because that's one click less. So it would be great if the general docs setting could be set once and are valid for all the users… Any expertise here in the group? Thx, Timm
I am afraid it is not possible at the moment. The Google Docs default settings cannot be changed in any possible way. Using templates would be the best option so that your users can just create a copy of the documents and keep working on the copies.
What you can do to make it easier for them to open the templates is to create bookmarks on their browser (only works in Chrome) so that they have a bookmarks folder with all the templates on it, so it is easier for them to access everything. For this you can use this Chrome policy in the Admin console to add control the managed bookmarks folder.
I have a couple of months using Google Chrome Web Developer dashboard. Everything was very normal, publishing an updated version was taking around 30-40 mins, now that I added a few elements to my extension such as popmotion.js it keeps requiring manual revisions and my extension gets into "Pending for Review" state for so long.
My question is: Is this caused by something I could have done in the code? Is it possible to get rid of this condition that keeps telling Google's services that my extension needs to be manually reviewed?
Thanks in advance!
According to this link, Pending review means the Chrome Web Store automated systems have flagged your item for manual review.
Some of the reasons an item could be flagged for manual review include:
The item may have an NPAPI plugin, which requires a signed agreement from you. Check your email account associated with the item for an agreement notification from our abuse team.
The item is suspected to contain or to be distributed by malware or unwanted software.
The item is suspected to violate one of the developer program policies.
The item may have already been previously removed for a legal or policy violation, and has been resubmitted.
The item requests powerful permissions that require in-depth review.
I'm Using OpenCart 2.1.0.2 and getting bot affiliate account daily 20 to 25 accounts. so i'm planning to disable completely affiliate module of Opencart , Please, anyone can help me regarding this issue?
I wrote a pull request to opencart that adds an option to disable the functionality: https://github.com/opencart/opencart/pull/7166. Once that's merged (or if you patch your code with it), you can shut affiliate marketing off in your store settings.
Login to CPanel, go to File Manager and go to your Opencart installation folder. Navigate to /catalog/controller/. Inside this folder you will find the folder "affiliate". Rename or delete it. Problem solved!
Steps I followed: Deleted both folders to disable affiliate pages /index.php?route=affiliate/login
/public_html/catalog/view/theme/default/template/affiliate/
/public_html/catalog/view/theme/journal2/template/affiliate/
But still getting 20 to 30 affiliate account registration daily.
Note: I'm using journal theme. – R
Well, first off, in your Settings (of your admin dashboard), make sure they require your approval. This way they don't just get an automatically-enabled affiliate account after they sign up for it (i think this should be an option in your version, but if not, follow the rest of this post anyway.)
Second, just remove the links and the tpl pages altogether to it, so that way they don't click nor sign up for it. For example, using the default template folder (default) navigate to:
template/account/affiliate.tpl - this file can be deleted
template/affiliate - delete the affiliate folder altogether
template/module/affiliate.tpl - this file can be deleted
Please make sure you backup these files anyway just in case anything. You should be done with bots/spammers trying to sign up now as there are no pages they can land on to sign up for affiliate-related things.
There are other things that can be done, too, but given the way you formatted your question and the vagueness in what you attempted thus far, this may be the simplest solution.
From the opencart admin left bar menu go to Extension -> Extensions -> Modules. Check if there's a module named Affiliate (by default it should be right below the Account module). Uninstall it.
I've been playing around with the new "Websites" feature of Azure (which I believe is still in beta), but I've run into a problem. I've got two subscriptions associated with my account - one for personal use, the other for my company. And of course, I'd like to be able to specify which subscription is used when I create a new website. But when I try to create a website, it always picks my second subscription, and never gives me a chance to specify which one I'd like to use. Nor can I figure out how to move the website to a different subscription after I've created it.
I've walked through this several times now, and I can't spot any place where I can specify which subscription to use. Is this just a beta glitch? Or have I missed something?
I ran into the same thing, called MS support. Switch back to the standard portal to make this change.
To get to the old portal hover over the green "preview" button at the top. This doesn't seem to work in Chrome for me, just IE.
Do take a look at my response on MSDN Forums for a similar question there: http://social.msdn.microsoft.com/Forums/en-US/windowsazurepurchasing/thread/d9624b03-1d6c-484a-9fa8-8548c35a9d4f/. Basically you would need to activate this feature for each subscription separately since it is in preview mode.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.