Delete projects from My Account > Projects

Permalink 2 users found helpful
I have several URLs for sites that were just set up as development sites listed under my Projects page - is there any way to delete these? I'd like to clean this out and get it set up properly so I can track what version of c5 is running, which add-ons, etc.

hursey013
 
Fernandos replied on at Permalink Reply
Fernandos
Good point! concrete5.org doesn't seem to provide that feature yet :(

We gotta wait.
frz replied on at Permalink Reply
frz
not yet, but yes should happen along with a handful of other tweaks to that stuff.
Mnkras replied on at Permalink Reply
Mnkras
i need it 2 :(i have 2 sites that have they exact same name :P its confusing
DigitalCrate replied on at Permalink Reply
DigitalCrate
me too please ;)
frz replied on at Permalink Reply
frz
you can change names ya know.
cursal replied on at Permalink Reply
cursal
Is this feature to just "delete" a project coming with the shiny new site and other upgrades?
frz replied on at Permalink Reply
frz
a feature to archive them is.
gour replied on at Permalink Reply
gour
Hiya!

Due to inability to get rid of old & unused projects, now I've a problem that my site is connected to the deactivated project (same name). Moreover, the site uses several add-ons which I purchased, and they are connected with the active project.

The problem is that, due to lack of the feature to remove old project, if I 'check for updates' I do not get anything (I've even bothered ChadStrat not seeing his update of ProBlog. Yiu can check the "There are no updates for your add-ons currently available from the marketplace" thread along with the attachments of screenshots in Pro Blog support section.

So, the question is how to disconnect my site from the deactivated one and connect with the active one and/or when do you think to provide such basic feature as to remove unused projects?
frz replied on at Permalink Reply
frz
This sounds off to me. We only allow you to archive projects, theres no active/inactive model on our end for just this type of reason

If you've rebuilt the database, yes you will end up with a new project page

You can also release licenses and reassign them to new projects

There is a howto on reconnecting to the community with a new project page if you need to, but this should certainly be an exception and not the norm. Deleting project pages is not on our radar

Best wishes
Pecked out on an iPhone
gour replied on at Permalink Reply
gour
> This sounds off to me. We only allow you to archive projects, theres no active/inactive model on our end for just this type of reason

Hmm, what is then the meaning of 'deactivate project' button?

> If you've rebuilt the database, yes you will end up with a new project page

The problem is that if one creates project on his C5 account site, it's not possible to connect it with the real site 'cause the process works only from the site to the C5 account and then, from the 'production' site it's not possible to connect to already created project on C5 site, but only to connect to the new project.

So, now I ended up with 12 archived projects which do not serve any purpose except being botheration. :-/


> You can also release licenses and reassign them to new projects

The best would be if such feature would not be there making one's add-ons eternally cursed to be assigned to archived (aka: uselass, dead, unusede) projects. :grin:

> There is a howto on reconnecting to the community with a new project page if you need to, but this should certainly be an exception and not the norm.

You mean, deleting those two rows from the Config table?

It really sucks.

> Deleting project pages is not on our radar

I really cannot comprehend what is justification for that?

What is so precious about old/unused projects that one is cursed to have them eternally listed there?
frz replied on at Permalink Reply
frz
I see the potential for orphaned data and sites that become unconnectable when the feature is used by our less tech savvy audience.

I'm not sure I really follow the problem you're having. If you have multiple copies of the same site for development/staging purposes they will all have copies of the same site key in their database, and they should all connect to the same project page

If you're making new sites from scratch, they will have unique database keys as they have different databases. They will connect to different project pages, as they should

Where does this fall apart for your process?

Best wishes
Pecked out on an iPhone
gour replied on at Permalink Reply
gour
> I see the potential for orphaned data and sites that become >unconnectable when the feature is used by our less tech savvy >audience.

I'm not speaking about "orphaned data and sites that become unconnectable..", but just about the question this thread was started with: "I have several URLs for sites that were just set up as development sites listed under my Projects page - is there any way to delete these?"


>I'm not sure I really follow the problem you're having. If you have >multiple copies of the same site for development/staging purposes >they will all have copies of the same site key in their database, >and they should all connect to the same project page

The point is that I've 'projects' which are simply "unused" - they existed in the past, but there is no longer any database which connect them to anything since we used

DELETE FROM `Config` WHERE CONVERT(`Config`.`cfKey` USING utf8) = "MARKETPLACE_SITE_TOKEN" AND `Config`.`uID` = 0 LIMIT 1
DELETE FROM `Config` WHERE CONVERT(`Config`.`cfKey` USING utf8) ='MARKETPLACE_SITE_URL_TOKEN” AND `Config`.`uID` = 0 LIMIT 1


to remove all the traces about them.

In some cases those orphaned projects even contain URL which do not exist any longer (e.g when testing stuff on my localhost).

>Where does this fall apart for your process?

Considering that I can remove keys from the database with the above two SQL lines, I do not see the reason why should I be destined to look at the list of 'Inactive projects' forever which does not serve any purpose?

Funnily enough, I use Fossil SCM as my DVCS and although it's designed not to allow stuff like git's rebase and changing the history, even Fossil allows one to 'shun artifacts' from its database.

So, I do not see who is served with this feature of not allowing to remove orphaned projects?

Are you afraid that 'customers' are cheating by using their add-ons on more sites than they bought licenses for?

I could understand that since I have Piwik installed to track who is visiting my sites. ;)
frz replied on at Permalink Reply
frz
If the use case that is bothering you is a messy list, I suggest archiving the projects

Best wishes
Pecked out on an iPhone
gour replied on at Permalink Reply
gour
> Deleting project pages is not on our radar

What about your statement from the last year "not yet, but yes should happen along with a handful of other tweaks to that stuff." ?

Broken promise?
frz replied on at Permalink Reply
frz
No, we added archive projects to make it easier to manage. Promise delivered.

Really deleting these thugs is going to cause more havoc than it will solve as we only can control our side of the equation

Best wishes
Pecked out on an iPhone
jlego replied on at Permalink Reply
I have a small problem with this. I have a project with 2 different "Found Locations", the dev site and the live site. I don't mind simply archiving projects, but it would be nice to be able to get rid the dev url while leaving the live url.
globalnerds replied on at Permalink Reply
globalnerds
When I initially created my site I did it as a sub folder i.e. patriotflight.com/gn - this way the site could be redesigned while the existing site was still up. I had to connect this site to the community in order to register some of my add ons. When I moved the site back to the "regular" domain. I had to reregister it. It now lists the site /gn as the MASTER site and the "regular" site as the child site. When I try to add a paid for (Crimson Red) add on, it adds it to the foldered site and the add on does not work. I need a way to delete both of these sites, then reconnect the now live site back into the community. Although the archive function is great, there needs to be a way to COMPLETELY DELETE a site from the projects page.

Any help on how to do this would be greatly appreciated.
mikemoyse replied on at Permalink Reply
mikemoyse
Yeah same situation here. This really sucks big time.
gour replied on at Permalink Reply
gour
> Yeah same situation here. This really sucks big time.

Indeed...It made me leave C5 and embrace SilverStripe, so I won't spend more bucks in the community where such sucking decision are going on.

Too bad I forgot to check 'stop monitoring' this thread - that's why I was 'forced' to remember it today. ;)
andrew replied on at Permalink Reply
andrew
I hesitate to open this can of worms again, but I feel like I have to. There appear to be two separate "problems" being described here. 1) a "master" site which is not, in fact, the "master" and a "staging" site which is not in fact the "staging" site, and 2) an inability to download the add-on to the right site. Is the entire problem really just #1, or is #2 happening? #2 definitely shouldn't be happening, and if it is I think there's a failure of communication somewhere, or something strange is happening that we should investigate. But if it's really #1, is that REALLY the biggest deal in the world?

I just want to be perfectly clear as to what you're talking about. I certainly don't think any of this particular setup is a "sucking" decision so if something is going on that we're not aware of I'd love to know about it.
gour replied on at Permalink Reply
gour
Hello Andrew,

I had a hope that C5 would become longer-term solution for my CMS needs, but issues like this one disappointed me (and led me to SS). :-(

This 'can of worms' was opened almost one year ago with a simple request: "I have several URLs for sites that were just set up as development sites listed under my Projects page - is there any way to delete these?"

Not considering many replies and attempts to justify your decision, your response is:

> I just want to be perfectly clear as to what you're talking about. I certainly don't think any of this particular setup is a "sucking" decision so if something is going on that we're not aware of I'd love to know about it

and my reply is that recently it was stated (again) in a plain words:

"there needs to be a way to COMPLETELY DELETE a site from the projects page."

Why you're ignoring it, is beyond me, and, now, I also do not care any longer.

However, it would be, at least, fair, to explain to you customers why/how this simple request is not possible to fulfill to be 'compatible' with your business schema. ;)


Sincerely,
Gour
frz replied on at Permalink Reply
frz
The reason we haven't spent our time doing this, but instead introduced the archive feature, is because we are concerned "deleting" and reconnecting projects will cause confusion. There's a lot of concrete5 site owners who are not as technically savvy as yourself, and adding this to the mix isn't going to make our lives supporting this ecosystem any easier.

This has already been explained, I believe even in this lengthy thread.

Moreover, I'm still at a loss on why its required. With the ability to release add ons, and connect multiple users to a single project page I have yet to hear of a use case that cant be handled. I recognize that it's something people feel intuitively should be there, and I'd like to do something about that. I hope you understand that managing complex projects like concrete5 is a series of compromises towards making everything work for everyone. If we can understand what's not working for folks, we can find a solution that makes sense.

Best,
http://about.me/frz
mikemoyse replied on at Permalink Reply
mikemoyse
I think the simple answer is that sometimes we make mistakes or host site a in a temporary location. I've done it whilst I've been trying out the system. Having our mistakes hanging around or keeping long dead sites seems a pointless exercise and will ultimately result in a huge lists for some developers.

Archive by all means but ultimately there needs to be a way of tidying up the mess and detritus that is inevitable.
frz replied on at Permalink Reply
frz
Yup. That's what we heard when we listened to this request, starting a year ago.

Thus, we added the archive projects feature so you could get them out of your face. Problem solved. ;)

The concerns I have about adding this all come from supporting site owners who contact us directly and we get to help on a one off basis today. Just to be clear, these folks have bought add-ons or are using free add-ons, have bought hosting, or are using hosting somewhere else, they're every bit as much our customers as anyone else. I appreciate you all sharing your desires to have an organized workspace on concrete5.org. I'll share some of the things we find ourselves spending considerable time explaining on a routine basis:

We find ourselves explaining the difference between a concrete5.org login and your own CMS login frequently.

We find ourselves helping folks who have bought add-ons with different accounts merge them into a single project page.

We find ourselves getting contact emails, typically in all caps, from folks hosting on budget hosts who have installed concrete5 and now want to uninstall it, but don't even know who to ask.

We find ourselves caught in the middle of ownership changes to projects. A developer is handing off the project to the site owner under some type of duress. A new project manager is coming into replace the old one who quit - that type of thing.

We find ourselves trying to stear site owners who are trying to debug issues that are completely unrelated but seem to think that reconnecting to the community might help.

Really basic stuff that I'm sure any of you guys would view as completely annoying to explain, yet we get the opportunity to rehash on a weekly or sometimes daily basis. My gut tells me that adding a "Delete Project!" button isn't going to make our lives any easier here.

What happens when that new project manager comes along and hits "Delete Project" and then contacts us saying "why can't I see the add-ons that our developer purchased for us?" Now I have no record of who, what, or where any of that happened. There's nothing at all I can have my boys do to help that person.

What happens when the site developer who is just cleaning up goes and deletes a bunch of projects they don't think they need any more and then I get contact emails from a site owner who can't upgrade their site? I have no record of anything, so again I'm left looking like a useless moron.

What happens when a site owner hits delete project and their website isn't deleted?

The way connect to the community works today is pretty simple. Your database has a unique key in it. When you connect to the community, that key is married to your project page. If you've got a copy of the site (ie it's using the same database) and you connect to the community again, it is added as a found location to the list and added to the same project page. If it's a new database, it's a new site, it's a new project page. If you release an add-on license from one project and assign it to another, we track that against the license. We can't push data out, we can't exclude a URL from getting updates if it has the same key. It's simply a log of what has happened, past tense. One might even call it a historical source of truth.

So deleting data from that trail of truth does nothing positive for our support challenges. People are going to use the delete button when they really shouldn't "I just want to remove concrete5 from my GoDaddy account, WHY IS DELETE PROJECT BROKEN?!??!" and people are going to use it when they could/should (you cleaning up your project list) and completely inadvertently do something that I simply can no longer undo. As you know, deleting is forever.. That's super dangerous in my mind.

Perhaps this comes down to just wildly different prospectives. Right now there are 54,165 project pages. I totally applaud your desire to keep your workspace organized - god knows it'd be great if my own desk were a little cleaner. I hope you can recognize that I've got some very practical concerns around keeping tens of thousands of people with very different levels of expertise happy. My experience has been you don't give kids sharp knives without a lot of supervision. Delete is a sharp knife. So the question I'm faced with is do I spend more of my own limited money, adding a feature which will make things potentially more confusing for more people, so a few people can have a UI they feel is more tidy. The answer is no. I'd rather spend that time and money on improving the core.

Thus every time I hear a developer say "I wish my list were more organized" I say "Use archive." It's not that I'm not paying attention, it's that I'm paying attention to a lot of different needs.

How about I have archive renamed delete and never show you projects again once you've archived them? Would that fix this problem? I recognize this request comes up enough that there's a kernel of truth to it being a need vs. desire, so I'd love to find a solution that helped everyone. Hopefully this lengthy post helps folks like Gour understand that there's quite a lot going on behind the scenes here and ignoring our customers is the absolute last thing we're doing.
Bronekk replied on at Permalink Reply
OK so what about this (small I believe) feature - add profile option "Hide my inactive projects". And then simply don't show them, instead put a note at the bottom of "Active projects page" "If you have any other projects, they are not not accessible because you selected option to hide inactive projects in your profile setttings".

Don't show a number of inactive projects, dont make it depend on whether-or-not there are inactive projects at all, don't do anything to push inactive projects in face of developers - just some really small print to let them remember they have this option turned on.

Just a suggestion.
frz replied on at Permalink Reply
frz
actually you can already do that. There's an archive projects feature
that basically works exactly as you describe.

We will be readdressing this at sometime in the future. I'm the first
to admit we don't have it perfect now. I also know that actually
giving confused people the power to delete data forever tends to
create more problems than it solves.

But yes, we will come back at this at some point.

best wishes

Franz Maruna
CEO - concrete5.org
http://about.me/frz