Leaderboard

Just going back to the option of storing it outside of the web root, it doesn't look like it would be too hard to create a new fieldtype based on the InputfieldFile.module Obviously this doesn't help you in your current situation, but I'm thinking out loud so ryan could possibly comment on this ryan - it seems that there is a $this->destinationPath variable. Whilst you can't link directly to a document outside the document root, is it technically possible to extend the module and have it create a folder outside the root, then set this variable to point to it (and on a page-by-page basis have it create a subfolder with the document ID as the subfolder name?). If so, then with a little work it wouldn't be too hard to have the path configurable (I think). Since you can't automatically serve a file that's above the document root directly, there would need to be a function in the module that deals with this as well, but I think that if this sounds do-able to ryan then I might take a stab at it at some point in the future (next few weeks are pretty busy, but after that then maybe ).

My solution is this. I keep list of all templates I want to shown on navigation on my site/config.php file: $config->navTemplates = 'home|basic-page|news|events'; I have templates like news-item, events-item etc who didn't make to the list. And whenever I loop normal navs I check against that list: $templates = $config->navTemplates; foreach($children("limit=50,template=$templates") as $child) { ...output here }

We don't have something like this built-in at present, but here are a few options: 1. Security through obscurity. Use a filename that it going to be impossible for someone to arrive at without actually seeing the link to it. The problem with this is that someone can save the link and forward it on to others. 2. Place the file somewhere outside of your web accessible files and use a PHP script (or PW template) as a download passthrough. I can provide an example if you are interested. 3. Use http authentication on the page's /assets/files/ directory. Using cPanel, SSH or whatever tool you have, secure the directory with a password. However, the user viewing the page will need to enter a password before it'll let them download the file.

Haha - I actually have no notifications, I just live here

MIGRATING A SITE FROM DEV TO LIVE FOR THE FIRST TIME STEP 1: Copy all the files from dev to live Copy all the files from your dev installation to the live installation. Whether you use FTP, rsync, scp or some other tool doesn't matter. What does matter is that you copy everything and that you retain the file permissions–More specifically, make sure that /site/assets/ and everything in it is writable to the web server. Here are some sample commands that would do it (replace 'local-www' and 'remote-www' with your own directories): Using rsync: rsync --archive --rsh=/usr/bin/ssh --verbose /local-www/* user@somehost.com:remote-www/ Using scp: scp -r -p /local-www/* user@somehost.com:remote-www/ Using FTP/SFTP/FTPS: I think this will depend on the FTP client that you are using as to whether it will retain the permissions of the files you transfer. Hopefully it will do that by default, if not, check if there is a setting you can enable. If not, then you may have to adjust the permissions manually in /site/assets/ and the dirs/files in there. Make sure /.htaccess got copied over too Depending on how you copied the files in step 1, it may or may not have included the /.htaccess file. Make sure that gets copied over, as many copying tools will ignore hidden files by default. STEP 2: Transfer the MySQL Database from Dev to Live a. Export dev database Export ProcessWire's database on your development server to a MySQL dump file. PhpMyAdmin or mysqldump are the most common ways to do it. Personally I use PhpMyAdmin because it's so simple, but here is how you would do it with mysqldump: mysqldump -u[db_user] -p[db_pass] [db_name] > site.sql b. Create live database Create a new MySQL database and database user on the live server and make note of the DB name, DB host, DB user and DB pass, as you'll need them. c. Import dev database to live Import the MySQL dump file you exported from your dev server. Most web hosts have PhpMyAdmin, so that's what I use to import. If you have SSH access, you can also import with the mysql command line client, i.e. mysql -u[db_user] -p[db_pass] -h[db_host] [db_name] < site.sql d. Update /site/config.php On the live server, edit the /site/config.php file. At the bottom you will see the database settings. Update these settings to be consistent with the database/user you created, then save. Most likely you will only be updating these settings: $config->db_name = "database name"; $config->db_user = "database user name"; $config->db_pass = "database user password"; $config->db_host = "database host, most commonly localhost"; STEP 3: Test the Site Your site should now be functional when you load it in your browser. If not, then enable debug mode: a. Turn on debug mode (only if you get an error) Edit /site/config.php and look for $config->debug = false, and change it to $config->debug = true. Then load the site in your browser again and it should give you more details about what error occurred. If you aren't able to resolve it, contact Ryan. b. Browse the site Assuming your site is now functional, browse the site and the admin and make sure that everything looks as it should. If it looks like stylesheets aren't loading or images are missing, it may be displaying cached versions from your dev site. If that's the case, you need to clear your cache: c. Clear your cache (optional) Login to the ProcessWire admin and go to Modules > Page Render > and then check the box to "clear page render disk cache", then click save. This should resolve any display issues with the site's pages. d. Practice good housekeeping Make sure that you've removed /install.php and /site/install/, and check to make sure that /site/config.php is not writable. While this isn't absolutely necessary, it's good insurance.