alan

Wow? Thanks Soma, I'm glad I started this post now! I had totally missed that re tabs!

I *do* know I can collapse fields but I've not made tabs. That sounds clever, how do you do that? PS: I was really just looking at the most basic "LIKE DUH!" moment I had when I realized a supremely simple change and then every edit where I kept scrolling down to edit, edit-scroll down, edit-scroll down, edit-scroll down, edit-scroll down, edit-scroll down, etc was unnecessary. Then I realized I was a clutz

Sorry to talk shop down the pub (as it were) but I just did something simple that made editing much nicer This is something that perhaps lots of us already do but I didn't. I rearranged my templates so the Body (and Sidebar if you have one, so the main content edit areas) are first in the template. Now when I create a new page I have to scroll down once to name it (subtitle it, whatever). But every other time I open it to edit copy the fields I from that point on almost always need are at the top I was just so glad I'd realized my mistake in not doing this until now I just had to share... Right, as you were and back to proper pub talk.

Hello, I am loving using _init.php to set stuff up and keep some constant info DRY. However I think I ran into a situation while I was working with Form Builder where I was (legally/sensibly) editing a file the Module uses to send emails and cheerfully went about referring to a var that I knew I had established in _init.php only to find it was not being found. I quickly realized this was because the file in question was not a regular PW Template file (but a Form Builder support file). But it left me wondering which is the best approach for globally defining vars: set them all in config.php so I am guaranteed that from *any* file I can access them by `wire("config")->myVar` set them all in _init.php and for those I can't access in rare cases like Form Builder files do something special like for those vars define them in config.php and have _init.php set a var so all normal Templates can access the same way set them all in config.php then in _init.php read them all from config.php and re-declare them as named vars (i.e. same as 2. but for all vars not just those that are needed by non-Template files)? I'm leaning toward 3. but any thoughts (particularly to do with not wanting to inadvertently bog down PW by doing something silly) would be most appreciated.

Very nice site and very helpful post noting Modules and threads, thank you for sharing Macrura and congrats on a great site.

Ah. That explains a lot. Famous (as I am (with my family at least)) hater of the bad joke that is the UI and UX of Facebook (regardless of any other failings it may have), I too would avoid a Like button that Facebookized my action in some way. Could we do this?

Thanks Ryan, that's sealed it for me.

visualcookie please excuse this advice, not trying to be a douchey know-it-all (I certainly don't know anything close to it all), but you can show teppo the love by clicking the Like This button on his post (you probably knew and just forgot in which case ignore this post).

Love it!

At the risk of 'pimping about' another thread where I've touched on /sessions/, I wonder if /sessions/ can safely be excluded in migrations and if so, then seeing no sessions created in /sessions/ would have made it easier, perhaps, in this case to spot the problem. Just a thought (here's the thread where I'm seeking to find the definitive list of stuff not to copy when migrating sites, in case it's of help anytime).

Not this threads topic but related to the comment below that made me sit up when I read as for me it links back to this thread which I am intrigued to know the de facto answer to since I think it will likely stop me ever having login problems again (only had them once so far but even once sticks out like a sore thumb on a system otherwise so entirely reliable). Tks for any comment over there and sorry for barging in here.

Without dis to interrobang, SiNNuT or myself; as SiNNuT said it would be great if someone who knew for certain what the list of safe-to-exclude folders was were to comment here, not urgent for me, just one of those things that comes back every so often so I finally thought I'd ask—looking forward to finding a definitive answer* in due course *Edit: The definitive answer to the narrow question "what files/folders can/should I exclude (when copy a sites files and it's DB from one place to another)?".

Thanks (and I hadn't even seen that setting in that Module )

Thanks interrobang and I'm sure that's right about the folders having to exist and be the correct permissions. When you say you clear the cache, do you do that just by manually deleting the content under ../cache/?

Exactly my problem too. In fact to make it even simpler what I was looking for was, given the 'traditional' and simple scenario of copying all files a site from a dev root setup to a production root setup, and exporting/importing the db too—what folders can (should) we safely exclude? There surely must be a 'definitely good to exclude' list so I too would be interested to learn what it is.

Thanks SiNNuT, list updated. I assumed if CACHE was copied (although I agree it's name sounds like it is not needed) and a full DB export/import happened also then the copy would be 'perfect' and everything would match and so copying CACHE would be OK. It's these not-quite-certainties of mine that I am trying to resolve together with looking for the cleanest set of files to copy when I copy a site the 'traditional' way (db export/import and FTP/rsync sync of files).

Thanks SiNNuT! I've not yet noted down (in my summary below) your ref to 'db stored sessions' as I don't know where they are; are they a collection of files somewhere? Exclude / Include list So far I assume the following should usually be EXcluded in a site copy /site/assets/sessions/ /site/assets/cache/ and everything else should be INcluded in a site copy (including these locations that one might have thought could be excluded) /* and that includes: /site/assets/cache/

Hi folks, I really hope this is not already answered somewhere obvious and I missed it or I'll feel silly... Summary What folders can I safely exclude when mirroring two sites files and DBs? More detail In other words is there a list of folders such as, perhaps /site/assets/sessions/ that can be safely excluded when copying sites and DBs from one place to another that will not disrupt logging in etc? I am not thinking in terms of what to watch out for such as config.php/config-dev.php etc but only trying to work out what "temporary" or ephemeral files can safely be not copied and will not cause problems such as logging in even though I will often 1. export a sites DB 2. import the DB to the other site 3. sync/copy all files (except some excluded folders?) 4. go to login (etc) on the remote site Thanks for comments, cheers, -Alan

Thanks adrian and Zahari—checking out rsync and OSX ref bookmarked!

On a completely other topic I was looking at rsync for webserver backup and as I was new to it the initial intro read was exciting as it looked like such a robust technology. So I'm very interested to see you use rsync over FTP SFTP etc and I've seen only good comments so far re arRsync (rsync for command line weaklings). Off to go have a play, thanks for the tip Ryan!

Sorry I didn't get to test it Adrian, I'm sure it would have been a redundant test and I'll be trying this out next site I build, congrats on the Module and thanks!

Thanks very much for that analysis Ryan. It's good to read you think it's 'files' not 'database' and reading your comment I think that too. I used Transmit.app and hopefully but perhaps not coincidentally it had crashed occasionally. On this occasion I was very careful to check it really thought the two sites were fully in sync but I am not confident that that test necessarily checks permissions etc and so perhaps it was an initial bad sync from my FTP that then got overlooked on subsequent check-sync runs. Long story short, confidence still at 100% in PW and robustness (the most polished product of it's type I've used) and I'm off to look at alternatives to Transmit (tho there is much I like about it). Cheers!

@adrian This module is exactly what I was looking at doing before, but done better, so thanks again. I've not read up on Page Path History but I see your question re that or this module. I like the idea of this module, my only comment would be that perhaps the approach the BBC take might be better, it's the same as yours but instead of http://www.mysite.com/1234/articles/my-article-title/ they use http://www.mysite.com/articles/my-article-title-1234 I assume as the result may be slightly better SEO-wise.

div style="color:rgb(0,0,0);font-family:Times;font-size:medium;">Strange inability to migrate Hanna between two hosts I have a local dev site that I copied to a remote dev site. All good (copy of files, export and import of DB). Then on the remote dev site I added Hanna module, all good. Now I have just re-sync'd the files back from the remote site to local (and sure enough the Module files for Hanna came down) and exported the remote db and imported it locally. All good, PW works AOK. Except however, the local system seems to only partially know it is meant to have Hanna. If I look under Admin > Modules it's not listed, but there is a menu item for Setup > Hanna and I can visit it and PW admin says "This page has no Process assigned". To date with all sites I have always used Navicat.app to simply Backup/Import in whichever direction I needed a db to be copied and all good. I will try actually deleting the local database, making a new empty one and then importing to that (in case it's something weird there) and report back in this thread. Did that and it made no difference. Has anyone else had this problem? Update 2013-10-01-0822 EST: I took a snapshot of the site and db (in case) and then went ahead and used Modules Manager to install Hanna (even tho it was already sorta installed). The 'install' occurred without a hitch, as if Hanna was not there, and the codes that had been plain text on the site immediately changed to their correct output. Still puzzled and slightly concerned by this, hope reporting it is of some help if at some point it's debugged/explained. Update: I think based on what I suspect and Ryan's comment (below) it must have been a bad FTP, even tho I tried hard to rule that out (below x 2). Happy bunny

Hey Adrian, thanks for the Module, if I read that right, it looks like functionality I remember from Textpattern? If so then it was something I was trying to do (very poorly) in this thread, linked just in case it's any help (can't believe it will be tho )—actually that thread title is misleading, the post I was referring to was this one on that thread.