Leaderboard

New Module which adds 1 more, but very tiny green buttons to the page list. It saves minimum 3 klicks to change page status from hidden to visible. Edit: update 11.12.14 Module provides up to 3 (more) buttons in page list to toggle status (hidden/visible, published/unpublished and locked/unlocked). Enable/Disable the buttons in the settings (screenshot) ProcessPageStatusToggler.module

Sup. FieldtypeOpenWeatherMap [GitHub] This module fetches and stores current weather data from the OpenWeatherMap.org service and helps you manage icon markup. To limit requests, OpenWeatherMap.org’s JSON-response is cached in the database and only refreshed once the field is accessed and the cache has a certain age that you define. The fieldtype is sadly not multilingual, but you can configure the language of the weather descriptions OpenWeatherMap.org provides you with. It would not be hard to make the output multilingual by referencing weather codes and translating them with ProcessWire’s built in tools. You install FieldtypeOpenWeatherMap just like any other module, by placing the two files into ProcessWire’s modules directory. Once installed, you want to create a new field of the type OpenWeatherMap and assign it to a template. The template now has a text field that stores a city id. In the field settings, you may configure how and when the data is requested. That is, the requested language, units (eg. °C/°F/K) and the cache duration. The module does not provide you with built in icons or otherwise limits you to predefined markup (which I consider a good thing ). The icon in my example above is courtesy of Alessio Atzeni’s Meteocons (custom free license). To make generating icon markup a little easier, you can configure your own markup snippets in the module configuration: As you can see, in this example I’m using an icon font whose appearance is defined elsewhere in my CSS, but you’re free to put in image urls or just unicode entities or whatever. Rendering it is now quite simple. The following markup would result in something like the image above: <?php $w = $city->weather; $temp = round($w->temperature); ?> <p><?php echo "{$w->renderIcon()} {$w->description} at {$temp} °C"; ?></p> <h2><?php echo $city->title; ?> <span class="ico-rightarrow"></span></h2> <!-- irrelevant line --> The variable $w is now a WeatherData object that exposes the following properties: json //The raw JSON response from OWM timestamp //The time of the request city_id //The city id you entered in the admin sunrise //The time of sunrise sunset //The time of sunset main //The main weather name, e. g. “Rain”, in the configured language description //A slightly longer, more precise description like “occasional rain” iconcode //The internal icon code for this weather temperature //The temperature in the format you requested min_temperature //... max_temperature //… wind_speed //I believe the wind speed is also affected by the unit settings. As well as the method renderIcon(), which you already know. If you access a WeatherData object as a string, you will get the city id. This is so that the city id will correctly appear in the admin page edit form. I should mention that there is some more information in the JSON, such as wind direction. The module also exposes the method multiRequest(PageArray $pages, $fieldname). If you want to fetch data for a bunch of pages at the same time, you may want to use that so as to reduce unnecessary requests to the service. I haven’t really used this yet, so consider it experimental, I guess. As of now, this also disregards the cache freshness. If you’re still reading, there’s a chance you might be interested in using this. Allow me to clarify that right now there is no support for forecasts or historical data (yet?). Sorry :> Here’s the GitHub link: FieldtypeOpenWeatherMap.

Have you seen these posts: https://processwire.com/talk/topic/7441-using-git-instead-of-ftp-in-shared-hostings/ https://processwire.com/talk/topic/2885-what-filesfolders-should-be-added-to-gitignore-for-regular-development/ https://processwire.com/talk/topic/5417-using-git-with-a-cms-for-version-control-and-deployment-on-multiple-machines/ Might get you started.

Hello there, ProcessWire has been the perfect CMS for me so far but I always missed the Laravel way of doing things when working with PW. Therefore I've built a package that will integrate Laravel into ProcessWire. It's already working out really well and I can imagine a lot of stuff to come in future. Anyways I'm hoping for some peoples support / pull requests / ideas / opinions ... Here's the link: https://github.com/hettiger/larawire Enjoy!

Thanks for this - awesome. I have used OpenWeather, but not yet with PW and will need to in the next few weeks, so this will be a big timesaver. Another nice set of icons that work seamlessly with OpenWeather are Skycons: http://darkskyapp.github.io/skycons/

See options #1 (post to script outside PW directories) and 3 (post to same page) here: https://processwire.com/talk/topic/407-processing-contact-forms/?p=3106 If you go with option #3 you can intercept right within same page, call your module, do your stuff and return the data Btw, in case you were not aware...https://processwire.com/talk/topic/225-how-to-work-with-ajax-driven-content-in-processwire/ if($config->ajax) { // page was requested from ajax // can optionally include external php scripts // call your module and do stuff }

Looks very handy - thanks! A few minor comments: I don't see why it requires LazyCron I think you have the messages reversed - it says "Changed page status to 'hidden'" when it should say "visible" It would be nice if the message told you what page had its status changed I'd love to see this work via ajax, rather than a page refresh, or at a minimum, it would be great if the EDIT / VIEW etc links were turned on for that page after the reload I am not sure whether the obscurity of the tick/cross is really worth the reduced space usage - I would rather see hidden/visible, but maybe that's just me. Thanks again!

@pwired, I don't get your post. @hettiger, thanks for the module, looks interesting, have to look into it at a later point in time though.

@Deltanic, It sounds like you are doing after-the-fact debugging using the call-stack shown in the browser. I try not to do that as I don't find it as helpful as using breakpoints or single-stepping new code in my IDE of choice (chrome + xdebug helper & vim + vdebug.) In an IDE you get the full call-stack, variables, code, execution location and can use breakpoints etc. Regarding cleaning up the format of the xdebug callstack output - have you tried the xdebug stack-trace documentation? (There's plenty of good documentation for xdebug.) Like I said, I don't use xdebug the way you seem to want to so I can't help any more than that. I would recommend giving some kind of IDE a go - as I find it so much more convenient for debugging than in-browser stack traces.

Often times, creating a side project is first and foremost scratching your own itch Or to start differently: Currently, I'm developing a site where I need CKeditor (and later jQueryUI Datepicker) outside of the admin, in frontend. I searched Google and the forums and found an approach to follow - but during the research the site laravel-recipes.com came into my mind (since I'm currently also looking into this framework). It's content consists of small, spot-on bits of information, for example: http://laravel-recipes.com/recipes/269 Just to think out loudly here, wouldn't it be nice to have a ProcessWire counterpart of such a site? processwire-recipes.com for example? Target group: Developers, from beginner to advanced Difference to these forums: Stripping the discussion part, concentrating on the info; and if done properly: bypassing the mediocre forum search, better tagging Difference to the official tutorial section: Focusing on not creating a whole site, but modular parts of it. Single solutions. For example: First child redirects (shameless plug, but this is the format of information pieces I'm having in mind) Difference to the API documentation: Situation-based ("I need this and that") instead of architecture-based Laravel.io (forum), laravel.com (official, and doc) and laravel-recipies.com possibly prove that these type of sites can coexist in a framework ecosystem, so I guess a recipes site would not cannibalize this forum here nor the doc section. A recipe site like this would live and die with its content, of course. I would be ready to share all the small pieces of information I encounter that would make a good "recipe". But that alone wouldn't be enough so this project won't survive without contribution of the community. What's your opinion on this? Yea or nay? Update: ...it just took, erm, nearly three months,... but here it is: https://processwire-recipes.com/

Here you go: https://github.com/apeisa/PaymentPaypal-deprecated If you are trying to implement this one and not feeling lucky, just ask here. While developing this I played a lot with latest pw dev and shop modules. Everything worked just like they should - so I will move them out from alpha stage.

Overview Mobile Detect uses a lightweight PHP class Mobile_Detect for detecting mobile devices (including tablets). Installation 1a. Clone the module and place MobileDetect in your site/modules/ directory. [OR] 1b. Download it. git clone https://github.com/justonestep/processwire-mobiledetect.git your/path/site/modules/MobileDetect 2. Login to ProcessWire admin and click Modules. 3. Click "Check for new modules". 4. Click "install" next to the new SimpleContactForm module. Usage This Module extends $config and sets the following parameters: $config->mobileDetect = array( 'deviceType' => 'deviceType (phone, tablet or desktop)', 'browser' => 'mobile browser', 'operatingsystem' => 'mobile operatingsystem', 'device' => 'mobile device' ); You can access them where ever you want. See the example below: <body class="devicetype--<?php echo $config->mobileDetect->deviceType?>"> <body class="devicetype--{{config.mobileDetect.deviceType}}"> // twig Results in: <body class="devicetype--phone"> OR<body class="devicetype--tablet"> OR<body class="devicetype--desktop">

Hi, After the move to ProcessWire on one of our major websites, I had to build myself a module/plugin so I could use the Amazon S3 / CloudFront infrastructure. The module/plugin uses Amazon S3 PHP SDK and the idea was to provide a clean way to upload/backup files to S3 and distribute the assets via Cloudfront. The current version of the module/plugin will copy the page files to Amazon S3 so you can then serve the via Cloudfront automatically. Note that the files are still also copied to the server where your PW installation resides. There's an option to backup the deleted files to another folder on S3 because when you delete a file on PW via the admin, the file is also deleted from it's folder on S3. The module also supports Apeisa's Thumbnail module so it also stores the thumbnails on S3. Note that the native size() method to create image thumbnails on S3 is currently not supported. As it is, the module will only upload new assets, so beware that if you already have pages created with assets you'll definitely have errors, so my advice is to test this with a blank installation of PW. If anyone wants to test it and contribute to it, I think this provides a good proof of concept for a functionality that is requested by several users (me included). Please note that I'm not a PHP developer, my skills (very) limited and I'm aware that it can be improved and I'm open to suggestions, feedback and most of all, collaborators. The module is hosted on github here and it's available in the ProcessWire modules directory. Nelson Mendes

Hi everybody, I'd like to share with you another new module. It helps you to manage user ratings for pages in a very simple way. You can add a user rating to a certain page with a line of code: $page->ratings->add(4) If the user is logged in, the module remembers which page the user has rated for. For non-logged-in visitors, the module stores the pages, the user has rated, in the session. You can get a page's rating and its total amount of votes in a similar way: $page->ratings->average; // => 3.2 $page->ratings->count; // => 5 For more information about this module, please check out its GitHub repository. You can check out a working version of the module here: http://curium-cte.lightningpw.com Edit: The module is now available in the ProcessWire modules directory. Update: Ratings has been updated to version 1.1, including a new, simpler API accessor. As always - please comment for bugs or feature wishes. Thanks in advance, Marvin

Introducing PVC PvcCore: https://github.com/oliverwehn/PvcCore/ PvcRendererTwig: https://github.com/oliverwehn/PvcRendererTwig/ (coming soon) PvcGenerator: https://github.com/oliverwehn/PvcGenerator/ (coming soon) Each time I’ve built a ProcessWire page I’ve struggled with organizing (and separating) code, markup and stuff. Playing around with frameworks (backend as well as frontend) like Rails, Ember and stuff I really liked having a given structure, knowing where to put what piece of code. Therefor I started working on a MVCish way to deal with templates in PW that considers the $page object kind of the data/model layer and adds View and Controller upon it. First by just catching everything via a small processor file added to all PW templates as altFilename. I’ve digged a bit deeper since then and hooked into the native rendering process, have been refactoring my code base more than a dozen times. Now I got a first version that seem to work and I’d love some of you guys to try it out! PVC (instead of MVC) stands for Page-View-Controller, as it considers PW’s $page var the model/data layer. I’m still working on the README.md on GitHub to document the basics. So have a look for more detailed infos there. I’ll give you a short overview here: Code separation: PVC introduces views and controllers to your PW templates as well as multiple action templates. Controllers, as most of you already know, keep all the business logic. Controllers execute actions wired to routes (urlSegment patterns). Even routes with dynamic segements (e.g. /edit/:id/) can be defined and assigned to an action, providing input through $this->input->route. Values can be set on the controller to be accessable in your templates later on. It’s also possible to set dynamic values as closures to be calculated (e.g. using field values of the current page) on render. Also controllers allow you to set layouts, styles and scripts to be available in your layout or template. Logic can be shared through inheritance between controllers. Views introduce view helpers. Helpers are functions that are made available to you (only) within your template context. There are predefined ones like embed(), snippet(), styles() or scripts(). But you can implement your own helpers easily and share them among your view classes through inheritance. Action templates contain the actual markup. Every action defined in a controller uses its own template. So the same page can display content accordingly to the action that was addressed via urlSegments/route. Within templates you can access all field values and values set on your controller like globals (e.g. <?=$title?>). Modular renderers: PVC implements rendering through separate renderer modules. PvcCore comes with PvcRendererNative that gives you template syntax the good ol’ PW/PHP way. A Twig renderer is in the making. And maybe you want to build your own renderer for the template syntax of your choice? I consider the module an early Beta version. So make sure to try it within a save environment! Would love to get some feedback (and error reports). I’m no professional developer, so code quality may suck here and there. So I’m glad for inputs on that, too. Also there is some old stuff in there yet, I still have to get rid of.

Google will use the content inside the page's <title></title> tags. There isn't anything you can do to change that, but you can change what goes in here in a PW template. eg: <title><?php echo $page->google_title; ?></title> assuming you have a field called "google_title" in the template for that page. Of course this will also be the title that is shown as the label for the tab in the user's browser as well, so bad choice of field name, but you get the idea Does that help?

It doesn't require LazyCron. Thats a copy paste bug . Thanks Adrian for the comments. I put it quickly together. Polishing will come soon. Thanks

@Kixie, Nice effort! Thanks. Not sure you know we already have a similar module? http://mods.pw/2y - ProcessPageHidden and one for un/publish - http://mods.pw/2z - ProcessPagePublish Btw, both yours and the ones I linked to are not really Process Modules

I'm using User class, it's nothing fancy I'm just logging in user via POST variables. So there is no need to even modify basic User class. I have ProcessWire 2.5.3 and it doesn't pass $this->wire->set('user', $myUser); for my template. This works though: $this->wire->set('api_user', $myUser); My first solution at this point was to set $this->wire->set('api_user', $myUser); and in _init.php I just simply assign $user = $api_user; But in my case this is much cleaner solution is to forget the module and put whole code in _init.php. Thanks for help!

Not currently, but it shouldn't be too difficult to add while Mike Anthony gets his version complete. I'm looking forward to his version myself—so long as I can specify my alt domain. *wink*

@benbyf - I don't think Tom did it that way. I do hope to get my module (which will fully support such redirects) up soon - still got a bit to do on it... Sorry for the delay guys... I'm sure that there are a few people who need it. Will get to it as soon as I have the time.

@ivan not sure I follow $allDescendantsOfEvents = $pages->get('/events/')->find(""); Too many code examples in this thread that makes no sense. You don't want to return ALL descendants to then filter them again by parent etc. In my cases this could return 100k pages it then filters 100 pages from that...

@Deltanic, I've just been stepping through the ProcessWire code and spotted a potential lead for you. Try commenting out line 205 and then 217-227 of index.php in the root of your development site install.

The function seems a little overkill, but why not. After all to get the grandchildren you only need something like $grandchildren = $pages->find("parent=$page->children, sort=-modified, limit=20"); That's already a function right there. One can of course wrap it into a function and play around with it.

@Raymond - if that's what happens then it is working correctly . Blog does not automatically associate permissions and roles. That would be assuming too much. It is left to you to set up. To help you, it creates the role 'blog-author' and a permission 'blog'. The role 'blog-author' is used to find and list, uh, Blog Authors' posts. The permission 'blog' is used to grant view access to the Blog Dashboard. So, as per normal PW access control setup, you will need to assign roles/permissions to your users at both the access and template level. You can still create additional permissions/roles to fine tune who can post, publish, edit, posts, etc. So, if you want your user to view the dashboard you can add the permission 'blog' to the role 'blog-author' (or any other role you create) and give your user that role. If you want them to access the Blog pages tree, you can do that at the template level. E.g. create a role 'blog-editor', and use that to control template-level permissions for Blog pages (view, edit, delete, etc). You can take advantage of PW's cascading permissions feature (i.e. children inherit parents'). Please note that if you do not want users to be able to delete Blog posts at the template level then you should also not give them access to the Blog Dashboard since they will be able to delete posts anyway. I have not had the need to add such an access control at the Blog Dashboard level beyond checking if they have 'view permission' ('blog') and for the 'Cleanup' utility, that they are supersusers.

Think I found a solution to the problem, thanks to this reply from ryan. To get the grandchildren of a specific page, here is what I did: <?php // Get a specific set of grandchildren pages under Projects page $parent_page = wire('pages')->get('/projects/'); // Define a variable and the parent page whose grandchildren you want to get, here I need it from the page 'projects' hence get('/projects/') foreach ($pages->find("template=photo_page_template, parent={$parent_page->children}, include=all, is_featured=1, sort=-date, limit=3") as $child) { // This part parent={$parent_page->children} is what does the magic here ?> <a href="<?php echo $child->link_to_page->url; ?>"> <img src="<?php echo $child->my_image->url; ?>" alt="<?php echo $child->image_desc; ?>"/> </a> <?php }; ?> It works! Tested with newly created 'Events' page in my project structured as follows: Home |- Projects // name=projects |- Nature |- Featured Image // Hidden & Unpublished, has a checkbox 'featured', checked |- Another Image // Hidden & Unpublished, has a checkbox 'featured', unchecked |- Another Image //Hidden & Unpublished, has a checkbox 'featured', unchecked |- People |- Featured Image // Hidden & Unpublished, has a checkbox 'featured', checked |- Another Image // Hidden & Unpublished, has a checkbox 'featured', unchecked . . . |- Events // name=events |- Photography 101 |- Featured Image // Hidden & Unpublished, has a checkbox 'featured', checked |- Another Image // Hidden & Unpublished, has a checkbox 'featured', unchecked |- Another Image //Hidden & Unpublished, has a checkbox 'featured', unchecked |- Advanced Photography |- Featured Image // Hidden & Unpublished, has a checkbox 'featured', checked |- Another Image // Hidden & Unpublished, has a checkbox 'featured', unchecked . . . By changing: $parent_page = wire('pages')->get('/projects/'); to $parent_page = wire('pages')->get('/events/'); only the results from the 'events' page were returned I have worked up a rough function to get the grandchildren of a page, it works perfectly in my case, excuse the code-smell. Usage in comments. <?php /* * Function to get grandchildren of any page * * Required arguments are $parent_page and $template_name * * NoteToSelf: REMEMBER: This function returns grandchildren of a page a.k.a children of children, so * if you specify '/' as parent and 'some_template' as template, it will return an array of 2nd level pages * i.e. Home->sub-page->sub-page * * Argument passing example: * For $parent_page pass as '/' for Home/root or '/somepage/' for some other page * For $template_name pass as 'template_name' * [OPTIONAL] For $include pass as 'all' or 'hidden' etc [read ProcessWire Docs for more] * [OPTIONAL] For $sort pass as 'date' or '-date' etc [read ProcessWire Docs for more] * [OPTIONAL] For $limit pass as '0' or '10' or '999999999' etc [read ProcessWire Docs for more] * [OPTIONAL] For $custom_field_check pass as 'field=value' or 'is_featured=1' etc [read ProcessWire Docs for more] * * To skip optional arguments pass null * * Usage example using null: * * $gc = getGrandChildren('/', 'my_template', null, '-date', '3', null); * if ($gc) { * foreach ($gc as $child) { * echo $child->title . '<br />' . $child->name . '<br />'; * } * } * * Usage example using all arguments passed to the function: * * $gc = getGrandChildren('/projects/', 'photo_page_template', 'all', '-date', '3', 'is_featured=1'); * if ($gc) { * foreach ($gc as $child) { * echo $child->title . '<br />' . $child->name . '<br />'; * } * } * * Kay Lohn | https://processwire.com/talk/user/2149-kay-lohn/ * */ function getGrandChildren($parent_page, $template_name, $include = null, $sort = null, $limit = null, $custom_field_check = null) { // Declare variables $parent_page = wire('pages')->get("{$parent_page}"); // Initialize variable as a new PageArray() $grandchildren = new PageArray(); // Initialize a blank variable to store query $query = ""; // Check and process required values if (!$template_name) // Throw exception if not present throw new Exception('Template name is required'); if ($template_name) // Add to $query if present $query .= 'template=' . $template_name; if (!$parent_page) // Throw exception if not present throw new Exception('Parent Page is required'); if ($parent_page) // Add to $query if present $query .= ', parent=' . $parent_page->children; // Check and process Optional values if ($include) // Add to $query if present $query .= ', include=' . $include; if ($sort) // Add to $query if present $query .= ', sort=' . $sort; if ($limit) // Add to $query if present $query .= ', limit=' . $limit; if ($custom_field_check) // Add to $query if present $query .= ', ' . $custom_field_check; // Run loop foreach (wire('pages')->find($query) as $result) { $grandchildren->add($result); // Add each result to PageArray } // Experimental if (!empty($grandchildren)) { return $grandchildren; // Return the page array } else { throw new Exception('No results :('); // Throw an error if PageArray was empty } } ?> I hope this proves useful.

I don't ever use the ternary operator for stuff with more condition level, if that's what it's called. It's just not readable at all, and I think without setting brackets properly the result can be unexpected. Only ever one ? and one :

Welcome to the forums! The $user variable is already taken in the globally accessible wire/fuel object, so don't use that. from your module you can set the var as follows (in your before page render hook): $this->wire->set('foo', 'bar'); in your template you can call it like any other wire/fuel variable (like $user, $page, $session etc), since the they are passed to templates automatically: echo $foo; // 'bar' More on THE fuel/wire: https://processwire.com/talk/topic/3876-using-fuel/ Soma:

Never said Laravel would be the only PHP framework. You can do all that stuff in other Frameworks or ProcessWire itself too. This is for people that enjoy working with Laravel and want to use it together with ProcessWire.

@Deltanic, I use xdebug with PW almost daily. It works great and I don't need to disable any PW exceptions to get it working. In my case, I use xdebug along with the vdebug plugin for vim and the xdebug helper extension for chrome (similar ones exist for FF) and they do take some configuration to get right - but none of it in PW. Could you explain exactly what problem it is you are having with using xdebug?

PW is not 'failing' for a dumb reason and it tell you what has gone wrong. You can do a try & catch to handle it.

So Resolution is the same. What about Pixel Density, Browser and OS Versions? Maybe the monitor is just misscallibrated. 25" with 1024x768 sound a little bit strange too...

Yes...Nothing this side of 2014 I am afraid. ETA February/March 2015 at the earliest...

I think hanna code makes the most sense here, but of course if you'd rather avoid that for some reason (maybe no other needs for it on the site, or whatever), you can always do your own replacement. Have your editors enter [[gallery]] somewhere in the body copy and then in your template do a simple: echo str_replace("[[gallery]]", $galleryCode, $page->body); You just need to define $galleryCode in your template code somewhere before the body is output.

Hello, So I'm working on a PW project in a shared hosting like Hostgator. For this to work you need ssh access, and of course git. I always have problems working with FTP, I feel my productivity decreases when using them, also you have no control over changes that are made. So a single file deletion could cause a big catastrophe. The first thing you have to do is cloning the PW repo, and checkout to dev branch Here we clone the repo, use the dev branch. Delete the entire PW git directory and initialize a new one $ git clone https://github.com/ryancramerdesign/ProcessWire/ $ cd ProcessWire $ git checkout dev $ rm -rf .git $ rm .gitignore $ git init $ git add . $ git commit -m "Initial Commit" Note: The file .gitignore from the dev branch have some files that you want to be commited, like /sites. I recommend deleting that file and create a new one. Ok, now we need to configure our remote repo inside the shared hosting. You need to login using a terminal. Linux and Mac have ssh already installed, if you are in Windows you can use Putty. ssh username@domain.com -p 2222 ... Enter your password: ********* Now we need to authorize our computer in the hosting, so we can push the commits. We need the contents of ~/.ssh/id_rsa.pub located our computer. A more complete guide for generating such keys is available here. Then we will copy the contents to ~/.ssh/authorized_keys. create the authorized_keys in the hosting if not exists using touch ~/.ssh/authorized_keys The next step is creating a new repo and configure some hooks in our server. $ mkdir www/processwire $ cd www/processwire $ git init $ git config receive.denyCurrentBranch ignore $ cd .git $ cd hooks $ touch post-receive The contents of post-receive hook should be. (this is a ruby script, but could be any language available on the server) #!/usr/bin/env ruby # post-receive # 1. Read STDIN (Format: "from_commit to_commit branch_name") from, to, branch = ARGF.read.split " " # 2. Only deploy if master branch was pushed if (branch =~ /master$/) == nil puts "Received branch #{branch}, not deploying." exit end # 3. Copy files to deploy directory deploy_to_dir = File.expand_path('../') `GIT_WORK_TREE="#{deploy_to_dir}" git checkout -f master` puts "DEPLOY: master(#{to}) copied to '#{deploy_to_dir}'" # 4.TODO: Deployment Tasks # i.e.: Run Puppet Apply, Restart Daemons, etc Now we make it executable using chmod $ chmod +x post-receive With all that done, we should enable a passwordless login so we can push without a password prompt on every push. In our local machine look for this file ~/.ssh/config And add this text (Change your-domain.com and port as needed) Host your-domain.com Port 2222 PreferredAuthentications publickey Now we should go to our project directory and add the remote host with $ git remote add hosting user@domain.com:www/processwire $ git push --set-upstream hosting master This should do the trick for commiting changes and upload files without ftp. Now we must install Processwire and then pull the changes. Go to your domain and start PW setup. once you are ready installing processwire, you need to pull changes that PW installer made. Login to your hosting via ssh and commit the changes that installer made. $ ssh user@domain.com $ cd www/processwire $ git rm $(git ls-files --deleted) $ git add . -f $ git commit -m "Initial PW Setup" When that is ready go back to your local machine and pull the repo. $ cd Processwire $ git fetch $ git reset --hard hosting/master Now we are finally ready to start working with PW in shared hosts or other machines that have ssh enabled. simply makes changes like $ touch site/templates/welcome.php $ git add . $ git commit -m "Added welcome.php" $ git push Now if you have some problems you can zip the setup using $ git tag -a v0.0.1 -m "Initial PW Setup" $ git archive --format=zip --output=pw.zip v0.0.1 And download the file and work from there Thats all References: http://www.arlocarreon.com/blog/git/push-git-repo-into-shared-hosting-account-like-hostgator/ http://ahmadassaf.com/blog/miscellaneous/how-to-use-git-to-host-and-push-projects-on-shared-hosting-services/ http://motorscript.com/setting-up-a-remote-git-repo-on-shared-server-like-hostgator/ http://krisjordan.com/essays/setting-up-push-to-deploy-with-git http://git-scm.com/book/en/Customizing-Git-Git-Hooks

Thanks for the quick replies. @Soma, enabling url segments is a great idea (wish I'd thought of it) and it did the trick. The way it ends up as far as URLs go, is like this: http://example.com/pw-managed-page/#/start-of-angular-routes. The code for my router configuration is like this: var MyAppRoutes = angular.module('MyApp', ['ngRoute']); function routeConfig($routeProvider) { $routeProvider. when('/start-of-angular-routes', { // note that it DOES NOT include the pw-mananged-page controller: AppController, templateUrl: '/ng-templates/app-template/' //don't link to file system html pages }). otherwise({ redirectTo: '/not-found' // angular managed page not found }); } MyAppRoutes.config(routeConfig); Thanks so much for your help. Much appreciated.

In case you didn't know or had forgotten, in PW you can edit /site/config.php and set $config->debug = true; to help track down errors. I've often found 'soft errors' (bad practice PHP etc (something you get if you are PHP 'lite' like I am)) that were previously hidden are displayed when this is set to true. But I also found I set it and forget that it's set then sometimes see a page load slightly slowly or with a visible 'flash' and wonder what's wrong, only later remembering I have debug left on. So now as a reminder I echo (if the setting is true) a reminder somewhere obvious such as adjacent to the homepage (or every pages's) H1. It's good to be reminded since going to a production site with it set to true is NOT recommended (API doc). This is the simple test and echo I now add: if(wire('config')->debug) echo "<span class='alert'>Flashy? Slow? Probably because of \$config->debug = true;</span>";