We Keep Coding

How to know which site are running my module?

I am about to sell a module that I coded for e-commerce websites, and I was wondering if it's possible, to insert some extra code in it in order to know which websites are running the module.
In other words, let's say a customer buys my module, then install it on its website, is there a way for me to know which website it is ?
I don't want any other info than "which website", my goal is not to trace users, but simply to have a statistic of the number of websites where my module is installed (because, it can be for instance that a customer buy the module then install it on several other websites...)
Thanks for your help
Aymeric

Difficult to answer without knowing what you are running, PHP, JS, etc. but when I created a similar plugin for WordPress there are some hooks for when a plugin is activated/deactivated. I just put an HTTP call into my API that told me when someone activated or deactivated the plugin and I got a rough idea. I mean, if they don't deactivate it properly, e.g. delete the files, then you would get a false positive of them using it, but not many folk do that.

Is it possible to edit and save website content to server, making the change viewable by everyone?

I have created a website for a third party, who have no experience in editing HTML. However, the third party wishes to be able to edit the content on the website without having to open the files and edit it this way, they wish to do it somewhat WYSIWYG (For example, hit an "edit" button for the content they wish to edit). Is this possible to achieve? It is not an internal website, it has user tracking (this should obviously only be available to admin users).
Is there a way of making contents of a div editable, then saving the change directly to the server, so the content gets updated publicly?
I am currently researching the topic, and although I have found some indications that the solution may be a PHP script, I have yet to find any definitive solutions or examples of similar functionality.

Yes you will need a backend language or framework to archive this. Where Javascript is used to interact with the page, the actual storage of information requires a database or similar technology.
Unfortunately which backend language or framework to choose really is the million dollar question. It largely depends on exactly what you are trying to accomplish, what your client or user is comfortable with, and how much experience you have programming.
PHP is fast and time tested backend language. Node is the new kid on the block, and it very popular also. Java and dotNet are on the way out. You can dig up a bunch more including Go, Python, Haskel, Etc.
You can use a languge listed above and start scripting away, but this can be time consuming and error prone. Most people use a framework to get started, and program using that framework's tools. The most popular PHP framework is WordPress, but it is designed for blogs and might not fit your use case. I use the framework Craft CMS which is very customizable. But the way you are phrasing the question a framework might be overkill. This is really up to you to decide after doing research into the available options and comparing them to what you wish to accomplish.
For the WYSIWYG, you might want to look into the following tools for the client to edit content:
https://imperavi.com/redactor/
https://ckeditor.com/
Hopefully this provides some direction, happy coding!

OSS License for "look but don't use it to compete with us"? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Is there a well known Open Source license that would allow me to open source some mission critical code in such a way that the community could read it, but that would simultaneously prevent competitors from using it to gain an advantage over us?
I'll give you a bit more context. We are developing quite a complex and serious business analytics tool for which we decided to create our own in house javascript MVC framework. As part of the project we also built a bunch of reusable controls that seamlessly integrate with the framework for things like switches, tables, autocomplete search boxes, navigation controls, etc. (think Cocoa controls or jQuery UI).
We'd like to release the framework itself and the controls to the community for better or worse under the Apache2 license, fairly standard stuff there. However, and this is really what I'm asking, we would also like to show the source of our SaaS analytics app (the one that powers our business and generates revenue) for the purpose of demonstrating how a complex enterprise app can be built on top of our framework, for it to be sort of like a rigorous proof-of-concept/case study/demo. But we don't want competitors to just clone the repo and deploy it on their servers with some rebranding and start stealing our customers. Is there a well known open source license that could facility this type of information sharing for the benefit of the community whilst simultaneously precluding competitors from gaining a competitive advantage from it? (I mean obviously our competitors might learn a thing or two and that's fine, but we want to have legal power in case they blatantly copy parts of our code and use it to compete against us; and the judgement of whether they are copying or not should be at our sole discretion).

I think you should look at the Microsoft Reference Source license..
Microsoft does pretty much what you outlined up there with the .NET library.
But as always with these license questions:
Don't take the word of a bunch of internet strangers - ask a lawyer familiar with the topic before you do anything you might regret.
Also, on a side-note: With all my love for OSS software - Regardless of what your competitors do, the second they have your source they can blatantly copy you (and they will if you are successful enough). And once that has happened you have to spend a pile of money on lawyers trying to get to your rights.
Especially when it's the heart of an operation, I'd label that as "competitive advantage" and not release it to the public. It's your IP, once you give it out to someone anyone can simply take your ideas and write his own app with it - no license in the world can prevent that (besides stupid patents you probably don't have).
So my advice here would be to just wait a bit and see how the MVC lib turns out.
Look at Ruby on Rails. It's been developed as part of Basecamp at 37 Signals, but the Basecamp source code never became public simply because there is no need for that. If the framework is any good people will use it and you'll get organically to sample applications.
Having real world examples is nice, but especially for JavaScript frameworks you should aim to be pretty backend-agnostic - so it shouldn't really matter if you run ASP.NET MVC or Rails or Node on the backend. The logical consequence is that the backend code is of no real interest to your library users.
They can see the library working on your site, that in itself should be enough to show useful usage patterns.
If you take some parts out of your app and show them to users you'll be fine without the risk of lawyering to get to your rights..

No. The purpose of any Open Source license is to give the code to the community to further develop, fork, or use for other purposes. The whole point of having a license is purely to prevent complete theft of code without attribution. If code that is claimed as original appears down the road can be proven to be based on your work, you have sufficient grounds for legal action.
The best way to demonstrate a proof of concept is to take discrete parts of your work as an overall demonstration of the value of the framework.
But, I'm no lawyer so I would suggest that you consult with one before doing anything that might jeopardize your business or your job.

Magento - javascript reliance = huge usability issues

Ok this is a bit of a rant and a question combined - Why the hell is magento so reliant on javascript?? This goes agaisnt all usability guidelines. WHats so annoying is that it even uses buttons instead of correct form submit elements. Why? This makes no sense what sense at all to me.
Why is this and is there a way around it?

The past five years have seen an increase of web application developers eschewing the common wisdom of of the late 20th and early 21st century by creating applications and require javascript as a baseline technology. Magento is following this trend because they want to provide a moden, AJAX enabled experience, and providing both a Javascript and non-Javascript experience increases both development and testing time.
Most decisions in the e-commerce industry come down to the ROI of increased sales. Magento has calculated/bet/decided that sales lost due to people having Javascript off are less than the cost of developing both a javascript and non-javascript experience.
As for their use of the HTML button attribute, Magento isn't a web page, it's a web application. Their architecture takes a Java like approach, including a UI that's abstracted away from the browser. This means PHP is used to tame the browser rather than using PHP to work with the browser. In this context button elements (driven by Javascript) make more sense. Take a look at Google Web Tools for another example of this.
The way to "get around" this is to not use Magento, or to customize Magento such that it fits your model of what web development should be. If your first response to this is "woah, that would take way too much time", then congratulations, you're thinking exactly the same way that Magento is. Magento, the company, isn't Microsoft, or Oracle, or SAP. They're a 200 person company, and expecting them to solve all your problems (for free) isn't realistic.
Welcome to 2010.

Magento's JS reliance is unusable in exactly one way: you cannot use the store without it. That's a big one (losing 1/20 of your customers is not a small thing), but ultimately it's a tradeoff that they decided was worth it.
As an example of the flexibility that you get as a result of this decision, consider the case of configurable products, especially with pricing differences. Magento allows you to create products that are configurable over N axes, in a ragged manner (some color/size combinations of clothing can be missing, for example), with different pricing for every single option. Doing that without JS would be tough, doing it elegantly (which Magento has, for the most part), is nigh impossible. By enforcing JS, the developers at Magento, Inc can spend their time implementing these kinds of features more quickly, which is to everyone's benefit.
To answer the question at the end of your post, no you cannot get by without it -- at least without writing a new frontend theme that reimplements everything from scratch, which nobody so far seems to have been able to do. Personally, the number of JS libraries that Magento uses seems pretty heinous to me, but nobody seems to have solved that problem either. The app is too complex and tightly woven to unwind that far.
Sorry it's not better news, but I hope that at least clarifies some of the thinking for the way things are.
Thanks,
Joe

"Why is this and is there a way around it?"
Although the front end uses Javascript heavily it is only essential in a couple of places. Configurable products is one. The one-page checkout is another but that at least can be disabled in System > Configuration > Checkout > Checkout Options.
Buttons with event handlers can be rewritten as a matter of theming, in some cases their destination URL is not the same as their form submission so a little forethought is required. In some cases buttons are not in the form element they are submitting, that is why they use script.
I will assume when considering accessibility you are not concerned about luxuries like image zoom and search suggestions. I notice HTML5 provides the datalist element for input suggestions but some sort of script would still be needed to update it beyond the initial suggestion.
Overall Magento is quite functional without Javascript, just not as out-of-the-box. An 'accessible' theme would make a valid extension should someone want to develop it.

We've just been looking into this when I came across this post (first time we've used the magento platform and our first project with it).
Typically we'd ensure that every site we develop degrades gracefully without javascript, but this is looking like it might be too much work for us on this particular project at least for the first phase (tight deadline alongside steep learning curve).
While I agree that javascript can offer some great usability enhancements, providing a non-javascript fallback isn't just about supporting the odd akward person who insists on turning it off.
Some users using disabled access devices (screen readers etc) as far as I know, might not have the option to use javascript either (or may find javascript interfaces more troublesome to use if not impossible in some cases). In these cases if it doesn't degrade gracefully for them, then I'm a bit concerned that it may conflict with disability discrimination legislation in the UK/EU (where our client operates).
For this reason, I'm not sure we can take the position the magento developers have in the long run (we'll probably end up backtracking and resolving this ourselves ultimately and I'm guessing that will take us longer than if it degraded gracefully from the start and we could simply build upon that).
The admin area is less of an issue, but the front end should work without javascript imho and I was a bit surprised when I discovered that it didn't work without it (the client came to us specifying magento so there isn't much we can do but run with it at the moment).

I think you'll find that the Javascript in most cases significantly enhances the usability. Trying to implement something like the Manage Products grid, Manage Categories tree or Promotions editor without Javascript would be a usability nightmare. When you look at the stats, well over 95% of browsers have Javascript enabled, so what's the problem?

Try using this site with java-script disabled. It works but start counting the post backs and you will see why usability trumps the few folks who insist on disabling java-script.

Using plugins that are not updated anymore

I have a simple question:
Would you rather use a plugin that is actively developed by the author(s) or use a plugin that is good in your perspective, but you know that it was last updated years ago and has no active support?

That is a tough call and depends on the circumstances. If you are responsible for a commercial software product you need to keep in mind that you always have to be able to ship product. If you can't because all the sudden the plugin doesn't work anymore some piece of the technology stack has changed you might have to face very unhappy customers ... In this scenario I would always go for plugins that are in active development/support and then only what is best for my team.
Staying mainstream has also its challenges. Each time you swap a tool, upgrade a piece of your technology stack, you take a risk. It is your responsibility as a software engineer to apply good judgement and then make the right choices.
For non-commercial projects I think it is less of an issue. If the old plugin doesn't work anymore you are under no obligation to find a replacement on short notice. In this scenario I would typically go for what works best for me.

I would use an old plugin if I felt that I could maintain it. In fact I already do use plugins that I've basically forked for one reason or another. Some plugins are small, and some are huge; it depends.
When jQuery goes through a major revision, it's not uncommon for APIs or behaviors to change.