Please, oh please stop me from doing stupid things

[Luke]

Please, next time you come out with a release rename the component folders.

components_public -> MainComponent
components_ucp -> UserCP_Comp
componen_acp -> AdminCP_Comp

And, last but no least please rename the files something different.

____-main.php
____-ucp.php
____-acp.php


Why would you want to do this? To keep people like me, who spend hours on end developing something, from overwriting their main component when uploading something like the userCP links.

I just did that today, and I feel like crap. Please keep me from doing something stupid now, so I dont do something stupid later.

Thankyou for listening!

*walks away, slams head into wall repeatively*

[Antony]

1.00

[bfarber]

I've actually run into similar issues - haven't ever lost my code because of it, but I like to keep one folder open to do work, but have to keep 3-4 because of this issue.

The *downside* is that components are intended to work during the upgrade since they are modular, and this would definitely mean existing components wouldn't work. Is it worth the trade off for users?

[Antony]

I'd suggest leaving this one until the code is overhauled and existing components will no longer work with the new version. Then you can introduce a change as all components will need upgrading.

[Guest]

Alternatively, leave the directory names the same - but add support for a new file naming convention ( mycomponent-main.php , mycomponent-ucp.php , etc ), as well as the old-style names.

So for example, a component named "dancom" could use:

components_public/dancom.php
components_acp/dancom.php
components_ucp/dancom.php

or

components_public/dancom-main.php
components_acp/dancom-acp.php
components_ucp/dancom-ucp.php

This method would benefit those who want filename differentiation, without breaking compatibility with existing components. :)

[Luke]

Alternatively, leave the directory names the same - but add support for a new file naming convention ( mycomponent-main.php , mycomponent-ucp.php , etc ), as well as the old-style names.

So for example, a component named "dancom" could use:

components_public/dancom.php

components_acp/dancom.php

components_ucp/dancom.php

or

components_public/dancom-main.php

components_acp/dancom-acp.php

components_ucp/dancom-ucp.php

This method would benefit those who want filename differentiation, without breaking compatibility with existing components. :)

I like that idea. I think the most important thing is the differentiation of file-names (the different directory names just gives you a better idea where you're at because some ftp's cut off the name with a ... until you actually get into it). If the file names are different, even if you upload it into the wrong folder you arnt going to overwrite your file :).

You could support the new preferred method first, and then if it doesnt exist go for the old style same-name-evil-prone-to-overwriting method :D. When you edit your component you could do a check to say "Hey this file is named this. Do you want to rename it this way? It prevents you from overwriting" or something :).

[Mark]

Why not just open your FTP client and tell it to notify you before overwriting files?

[Luke]

Why not just open your FTP client and tell it to notify you before overwriting files?

It does. I was a little quick on the draw to hit "yes" and I didnt realize what I had done until it was too late. You really cant notice until you really look at where you are. Easy to go to the wrong place, especially if unopened folders are abbreviated by the ftp...

[Brandon C]

Alternatively, leave the directory names the same - but add support for a new file naming convention ( mycomponent-main.php , mycomponent-ucp.php , etc ), as well as the old-style names.

So for example, a component named "dancom" could use:

components_public/dancom.php

components_acp/dancom.php

components_ucp/dancom.php

or

components_public/dancom-main.php

components_acp/dancom-acp.php

components_ucp/dancom-ucp.php

This method would benefit those who want filename differentiation, without breaking compatibility with existing components. :)

+1