I have baked a project in cakephp. I have done custom modification in the controller, when I bake the code again those changes are lost.
Is there any way to keep those changes?
I am new in cakephp please help..
No, if you keep the files in the app directory you will loose those changes because the Bake Console will override them.
What can you do then? Well you could:
bake inside a new app (just connect to the same DB) and then merge the changes with your existing Controllers. For merging you could use Diffuse - a very nice and small footprint merge editor which works on almost all OSs (Linux, Mac OS, BSD and Windows).
back up your existing application and bake over it. Then merge the changes you've done back to the application.
It should be better to use method 1. if your changes are more code than the parts that you wish to bake.
This could be a nice add-on to the existing console's functionality. Maybe via a diff from the original baked version and the current changed one. However I am not sure if this is needed, since the idea is to initially bake and then develop.
If you are just trying to Bake new controllers and don't want to overwrite your existing controllers, instead of using "bake all", you could use "bake controller". It would then prompt you for which model to use for the Bake.
Related
I have a website that creates from Laravel. I want to do some customization to that.
Can I edit directly from my server or need anysoftwair or anything else
I need help editing it. How can I do it?
Thank you
You can edit the files directly on your server using any text editor available to you, however, it's not advisable to make changes directly on a live/production environment. What happens if/when you make a mistake or a change has a negative effect (e.g. on performance), how will you revert those changes efficiently and swiftly, and how will you know which file(s) are causing any issue(s)?
Instead create a local environment to make and test your changes, ideally then deploy those changes to a remote staging/development environment for further testing before deploying to your live/production environment.
I added a framework to my project in Xcode written in Swift. There was some issue in the framework so I tried to modify and a dialog came out giving me the option to lock or unlock, so I choose Unlock and proceed.
Would it harm the owner? Would these changes continue with my project until my app is in the App Store? Please let me know if there is an issue with that and help with a solution.
Simply I need all framework files but I don't need all functions. In addition, I need to add functions to fit to my project.
It is not recommended to modify a third party pod's code, as it will be overwritten with the next pod update.
There are multiple solutions you can try:
implement the framework manually and modifying it there (keep in mind that you are losing the capability of quick updating)
modify it as an extension of the framework if possible, i. e. store your changes in a separate file and paste it everytime an update occurs (not recommended as it is not too convenient)
fork the project and make changes on that separate fork
create a pull request to the project that includes the modifications (if you think they are helpful for others as well)
There is a web app. Let's say I want to add a feature. I can write some code, test it locally, make sure it works - then publish it so it is available to the public. Some features though are very complex and not that easy to be written, tested and shipped the same way.
I want to make it so certain feature I am currently working on is not available to the public even though I publish the app.
Let's say I want to add a custom breadcrumb feature to the app (just for one page to keep it simple). I can write a block of code surrounded by some IsProductionReady variable maintained somewhere in Config file - then once I am done I can set IsProductionReady to True - so now it shows up.
I also want to be able to switch to any other features / changes and publish them without affecting any code, without showing any signs of Breadcrumb feature development. When I am done with the feature I want to be able to just make so it is available to the public.
What are the best practices or strategies to maintain a certain state of a feature? What is the best way to structure it?
If you're using Git, it's better to have a separate branch for each new feature, then after the branch being tested and approved you can merge them into your main develop branch, run another regression test (because different features may interfere each others functionality) and then move it to the Production branch.
Take a look into these urls, I presume you can find your desired scenarios in them :
http://nvie.com/posts/a-successful-git-branching-model/
http://martinfowler.com/bliki/FeatureBranch.html
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
I would have separate branches on Github between both and keep the structure the same. When your feature is ready, merge to the production branch.
Please bear with me here, because I'm a beginner when it comes to version control systems. I've decided to start with the very simple GitHub app. What I want to do is (because I work in Dreamweaver) when I save a file a window to pop-up and ask me if I want to commit, is something like this achievable and if so... then how?
Perhaps there's a solution that uses a directory watcher to watch for changes and then prompt?
In my opinion, this isn't really a good solution though - you don't just want to use Git as a "backup" solution, you want each commit to be a mini-milestone that represents some logical group of changes. I can't think of a single instance where the first time I saved a change to a file it was commit-worthy. If you were to commit with every save, how would you ever test those changes?
I haven't used it myself but the GitWeaver extension may be what you are looking for.
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.