- This topic has 13 replies, 3 voices, and was last updated 9 years, 4 months ago by
.
-
Posts
-
Hi, first of all, I feel like I may have missed some documentation. If the answers to my questions are obvious and answered in a wiki already could you point me to it? I've been browsing through and haven't been able to find answers so I apologize if i'm asking a duplicate question. Here' goes.
How do you customize your child themes efficiently? With regular php development you run the server locally, and make a change, save, and refresh the page to see the changes.
I have the server running and hello world works fine, but when I try to load localhost:8000/Development/blog/themes/genesis/index.php I get this: Fatal Error: Call to undefined function genesis() in /home/john/Development/blog/themes/genesis/index.php on line 15.
and running localhost:8000/Development/blog/themes/genesis-child/index.php is obviously going to give errors since it depends on genesis. Right? also.. should I copy every file into genesis-child and edit to my hearts desire or just the functions.php and style.css???
I am pretty sure I don't have to zip the folder, upload to wordpress and live preview every time I want to test a change, right?
Regardless of whether you are working locally or online, you should never edit the Genesis Framework theme itself. So long as child themes have the necessary code to define themselves as a child theme of the Genesis Framework, only the child theme needs to be active. It doesn't matter whether you're working locally or not.
As for the question of copying files, for most basic things, the functions.php and style.css files are all you need. Once you want to start customising individual pages and templates, then you can start creating new templates.
Hell, my Genesis child themes often are a mix of templates, template includes, scss files, js files and a whole other host of things. However, don't try to run before you can walk.
Thank you for the input. Just to clarify, I haven't done any editing of the Genesis Framework theme itself. I copied the functions.php and style.css from the genesis theme into a genesis-child directory. Now I want to get the theme running on my local server so I can do some edits, save, refresh and see the effects of my changes.
In my genesis-child directory I have copied the functions.php, style.css, and index.php files from the genesis theme and pasted the duplicate in the genesis-child directory. When I run the code locally I'm getting the error:
Fatal Error: Call to undefined function genesis() in /home/john/Development/blog/themes/genesis/index.php on line 15.
but now that I think about it, the local server needs access to the database too. How do you get up and running on your local server so you can edit and make changes and not have to re-upload the project and "live preview" just to see a change?
While I don't have it figured out yet, I believe I found a solution in Chapter 3 of the book professional wordpress design and development 3rd edition.
Even easier. Invest in Desktop Server. It's well worth it.
https://serverpress.com/get-desktopserver/
Make sure you get the Premium one. It'll make uploading locally developed sites easier too.
Hi There,
We specifically take a different approach and cut out local development; here's an overview, http://www.studiopress.community/topic/workflow-from-development-to-deployment-need-advice/#post-145541 we've been using it for a couple years now. I suggest to dip your feet in, you get a cheap value plan on namecheap which allows multiple WP installs and use something like example/wordpress-sub-install-dir/ (basically install different dev sites on different wp sub dirs) - namecheap's interface (cPanel) is cake to do this.
We use a slightly more involved process for dev, but to try out the overall process you can give the above a try.
If you like it, you can follow more on with our process - or get in touch and we'll walk you through in detail. We've found this to be much better to support and maintain long term wise than dealing with the pain of setting up local server, local db, local etc, etc
coralseait, Thank you for the response, I am definitely interested in your workflow. I read through your other post, and I sort of understand, I need to "digest" this information a little bit. I apologize if I ask noob questions, but I do want to make sure I understand.
- first of all, how quick is the process? Say your experimenting in development and changing background colors to find one you like and you need to try out 10 different colors. Do you just change the color, hit save, refresh, view the change and repeat? I always assumed that was the normal way of developing since that's how it's been in every language I've seen so far, (lol).
- you said to develop on dev.url.tld, and it looks like that is a subdomain? Do you go directly into cpanel and edit the files inside the cpanel area and save from there? How do you make the changes to dev.url.tld?
- Once you have the site the way you like it and are ready to push that to production, then you push the development changes to upDraft and restore the site using the newest backup version of the site stored in updraft (which includes the changes you made) and you are done?
Thank you very much for the assistance so far. For what it's worth.. My own experience developing locally was pleasant for the most part. I edit files in my text editor, hit save, refresh page, view changes, I repeat that until I am satisfied, merge that to the master branch, push to github and then run the command "git push heroku master" and my changes are live. I'm hoping to find that level of efficiency with wordpress development, Most importantly is the development portion since that's what I spend most of my time doing.
Anyways, thank you again, my apologies if these questions are so basic.
(I also use a flavor of Linux, so the server press thing is not an option for me, which isn't a huge deal. I don't mind doing the whole local LAMP stack thing if I have to.
My first and only change I made so far was a pain. I unzipped the child theme, made a background color change, re-zipped the file, uploaded that entire zip file to wordpress, went to the admin area and clicked live preview to verify that the color change was made. It was changed, but if I can't imagine having to go through that process every single time I make a trivial change.Oops. I'm sorry for the spam. With my own development experience that was in Ruby on Rails, NOT wordpress/PHP
Hi Again fastpenguin91,
Apologies if there's some confusion between my two thread postings on this; I'm jumping around on our solution for multi client support and a simple solution to try out our workflow without investing a ton.
I'll answer your questions below:
coralseait, Thank you for the response, I am definitely interested in your workflow. I read through your other post, and I sort of understand, I need to “digest” this information a little bit. I apologize if I ask noob questions, but I do want to make sure I understand.
No worries at all, happy to help!
– first of all, how quick is the process? Say your experimenting in development and changing background colors to find one you like and you need to try out 10 different colors. Do you just change the color, hit save, refresh, view the change and repeat? I always assumed that was the normal way of developing since that’s how it’s been in every language I’ve seen so far, (lol).
From our perspective it is very quick, because you are always developing on live servers. There's a few ways you can handle it, but because we have windows and osx development platforms we just use filezilla and sftp / ftp to push the changes to the dev the environment. We're big fans of sublime text editor as well, because between filezilla and sublime the platform is exactly the same for those that prefer windows or osx. Filezilla detects changes to 'locally' edited version of the file from sublime and uploads it. Then you browser refresh. There's of course many other ways, but this is pretty fast, 'live' and pushing to real server that mimics what production will be - and that's our biggest draw to this; we know the site will work when we migrate using updraft and we don't have to mess around with local lamp issues on dev machines. Basically you can think of it as using the pretty cheap plans available now days as your local LAMP (or LEMP, we use both) installs, without the need to manage them.
– you said to develop on dev.url.tld, and it looks like that is a subdomain? Do you go directly into cpanel and edit the files inside the cpanel area and save from there? How do you make the changes to dev.url.tld?
See above, and note it depends on our client / environment(s). In your case, to try it out cheaply and see if it works, just grab a cheap .com domain from Namecheap and their lowest end hosting package. Note, they often run 20% - 40% off coupons, just search namecheap coupons. Then install WordPress into sub directory. With Namecheap you get 25 WP sub installs (I think), so enough to test out parallel dev as much as you like. You'll create FTP account(s) in cPanel so filezilla (or whatever ftp) you use can send them up. They'll be as sub directories in your main account, so you can also use cPanels FTP into directory setting to skip navigating in FTP once you login.
Note, you can also go a bit more complex with sub domains, so dev.tld or whatever, but the above is to dip your feet in. We do both, and on our VPSs.
Full disclosure, We have NO affiliation with Namecheap - we've just been supported very well by them on their platforms (usually chat support solves things in 5 minutes) and you can't get much cheaper for a dev environment. If you want to touch on self-managed VPS, everyone recommends DigitalOcean, which is good but we're huge fans of RamNode - Again no affiliation.
– Once you have the site the way you like it and are ready to push that to production, then you push the development changes to upDraft and restore the site using the newest backup version of the site stored in updraft (which includes the changes you made) and you are done?
Yes, we use Google Drive and Amazon S3, and typically isolate sites by different GDrive OpenAuth credentials / S3 buckets to keep our backups secure. When we're ready to move a site to production we just push a full backup to Cloud Storage and then Restore to production from the appropriate Could Storage container / bucket. Updraft auto-magically takes care of URL / Database replacement and handles moving from Apache to Nginx to Lightspeed, etc like a champ. This also works VERY WELL in hosting outages, as we just temporarily bring up a new WordPress install on alternate hosting, install UD, authorise it to whatever Cloud Storage is appropriate, restore and update DNS. Because we use managed DNS that takes seconds to move sites around.
Thank you very much for the assistance so far. For what it’s worth.. My own experience developing locally was pleasant for the most part. I edit files in my text editor, hit save, refresh page, view changes, I repeat that until I am satisfied, merge that to the master branch, push to github and then run the command “git push heroku master” and my changes are live. I’m hoping to find that level of efficiency with wordpress development, Most importantly is the development portion since that’s what I spend most of my time doing.
Same here, but with many sites / clients, and often moving clients off of old hosting or inadequate hosting, etc we decided to leverage the cheap plans available (or our own VPSs) and eliminate a layer of IT support on our end. No need to manage VMs, LAMP installs, etc anymore, we just leverage Updraft and Cloud Storage to push things server to server - your specific implementation may be a bit different than ours, but the overall idea is to get rid of extra steps that really don't value add to the client and take up our time (they don't care about git or repositories or source control, or VMs or LAMP, etc) and our dev environments basically match our production environments. Because we're pushing server to server or server - cloud -server the bandwidth concerns are minimal as well. Note, Updraft allows fine grain control of backup or restore so you can do plugin, db, themes, core, others or any combination.
EDIT: And to be clear, with Filezilla's auto detect changes and push, we get the same efficiency as local dev but without having to manage our local dev environments. The biggest bit is initial wp install, ftp credentials and waiting for whatever file your editing to download or upload via filezilla to the dev environment (which outside of huge images or video, is nothing). If you do mess up, you can always use cPanel to fix and htaccess or functions.php issue, but a good editor (like sublime or others - often stops that). For the VPSs we just ssh in if we need to fix things. Namecheap will also grant you ssh, but we rarely have need to request it. Because we are using the cloud storage, the actual site migration, backup, restores etc are very fast as all the partners are on fast networks.
Anyways, thank you again, my apologies if these questions are so basic.
Of course, always happy to help other devs
Hello Again,
One more clarification, because I think this will help clear up a bit more. Within the Filezilla FTP client we just navigate to the file we wish to change on the dev server and select view / edit; we have it setup so that it launches Sublime Text based on the type of file (or another tool if necessary). We make our changes, and upon saving within sublime Filezilla detects the change and uploads the changed file back to the dev server. Presto, just like local dev copy, but using a cheap hosting service to deal with the management and setup of the environment for very low cost.
I know a lot of other FTP clients support upload upon change detection and other editors work fine, but for us Filezilla and Sublime Text are a great combo, because again their appearance and behaviour is the same on many platforms.
Thank you a ton for going out of your way to help. It makes perfect sense what your doing, and I love the idea of developing on live servers. I've experienced at least a couple headaches from differences between local and production so eliminating that sounds perfect. I should be able to get things up and running from here. I might pop back in and ask another question but I think I got it. 🙂
Cheers!
Sorry to throw a spanner in the works, but I would strongly advise against developing on a server. In fact, if I was interviewing someone and I found out there weren't developing locally, the interview would end there and then. I know many of the major agencies are exactly the same.
Developing on a live server is a form of cowboy coding and is frowned upon in the development community. Developing on a live server and then migrating to another server comes with just as many – if not more – problems than developing locally with a tool like Desktop Server and migrating the database and site using its inbuilt tools. In fact, I can spin up a server in Desktop Server – already set up with Genesis and my starter theme, with all my commonly used plugins installed replete with licence codes – in 30 seconds.
I can also upload the site to a live server in less than two minutes – again, with all the content, database and licence codes in place.
Developing online also makes developing sites in Sass (or LESS) near impossible (you'd need to complile locally, which defeats any benefits of developing online).
In other words, you can develop online – it does work – however it's frowned upon and if you want to move beyond being a freelancer, then you need to develop locally. Desktop Server makes it so much easier.
There's certainly pros and cons, but for all but the most complex projects we've found it far easier to replicate dev and production as near as possible and just dev on live cheap value hosting. We're not aiming to be large agencies or interviewing on Word Class software development practice.
From a personal perspective, I've developed for and implemented some of the most complex systems in the world using ancient source methodologies like cico files on mainframe to modern source controls like git and SourceTree and everything in between - and for simple websites, the simplicity of this works for us - but of course isn't the be all end all. Many ways to skin the cat we realise and this is just one.
- The forum ‘General Discussion’ is closed to new topics and replies.