Leaderboard

In regards to dev vs live htaccess, you can also use htaccess's "if" conditional for blocks of code you want to selectively enable/disable depending on the site being loaded. By doing so, you don't need two separate htaccess files to maintain. When using ProCache combined with it's htaccess recommendations at the top, I wrap it inside a conditional like this: ################################################################################################# # ProcessWire ProCache recommended .htaccess tweaks for expires and gzip performance settings. # PWPC-3.0 Keep this line here for ProCache identification purposes. ################################################################################################# <If "%{HTTP_HOST} == 'my-live-website.com'"> ...the code here... </If>

This approach seems totally fine. You could speed things up using $cache or even ProCache. Depending on the overall setup one thing might work better than the other. To be honest... build your structure, build up your content and when you reach 100-200 news/events/whatever type of content try playing around with different settings. Do it again and again. Always have a DEV environment to test those things. In most cases there is more than one way to get things done in ProcessWire. At first one approach seems to work fine but later on with more content and users another might work way better. I find myself quite often in this situation and rework things in projects after a while because of things and the amount of content changes. My opinion on this: Don't force them. Give them the option to choose what they want. Offer a nice "The last time you watched CITY. Go this way to get all the latest news for CITY." You never know why someone visited a particular city. Maybe just for interest or by accident. Yet again there is no real this is the best option to do this answer. In your case you might want to look at the page reference field and take a look at this post about categorising content and this post about getting references in different ways. You can also try the skyscraper demo @ryan did a while back. He is handling a lot of data and references there as well. This version of Skyscraper profile works with the latest ProcessWire verion.

It sounds like you may be confusing pages and tabs: the settings tab (included on each page) doesn't have a template of its own. None of the tabs do -- only pages have (or, more specifically, use) templates. This thread has ideas on how to hide the settings tab with code, and if you enable the advanced mode via site/config.php, you should find settings for hiding the tab and moving name to the Content tab. More details here:

Just used vex in a project where Kendo UI wasn't available (mostly we use that for admin pages), and it was a very pleasant experience. After all I'm happy that I had to find an alternative, it brings more sophisticated ways to do prompts, confirms, etc.

I use this plugin and it works nicely: https://plugins.jetbrains.com/plugin/7448-zero-width-characters-locator

Another hidden treasure in the PW Backend: PW 3.0.61 introduced the VEX library for dialogs: https://processwire.com/blog/posts/processwire-3.0.61-master/#admin-and-ui This is how you can use them in your custom admin pages: In your module's php load the vex library (eg in the ready() method of your module - init() might not work as it might load too early!) $this->wire('modules')->get('JqueryUI')->use('vex'); Then in your javascript: // show confirm dialog ProcessWire.confirm('Are you sure you want to delete this E-Mail?', function() { // on confirm $i.removeClass('fa-trash').addClass('fa-spin fa-spinner'); $.get('./trash/?mailid=' + $a.data('mailid'), function() { $a.closest('.RockGridWrapper').find('.rockgridbutton.refresh').click(); }); }, function() { // on abort grid.api().deselectAll(); }); Result: I opened a pull request with a little fix for handling clicks on the CANCEL button. If you want to support it, give it a thumb: https://github.com/processwire/processwire/pull/108

If you believe your client will sell the theme you did for them should already be a red flag. But there are a few things in mind. ProcessWire isn't that often used as WordPress, so selling the custom theme might no really pay off. If the work is highly customized it will be hard to sell it anyway. If your client paid you for creating a custom PW theme and not for a custom business website you are too late to the party in this case. Depending on your location (country and legislation) selling a custom theme/website might already break copyright laws - in this case you might only need a good lawyer. Being in an association or union might help as well - but depending on your country and legislation, offered services, contracts and some more details it could be too late as well in this case. For now or the future... if you have a bad feeling about clients in regards of "they will steal my work" make it more difficult to clone/copy your work. don't provide full sources of PHP/CSS/JS/SVG/PSD/AI/... add licenses/copyright notices with your details within a license.md/.txt add license/copyright details in your main files add and use custom namespaces for functions, classes, whatever never work without a contract never work without those details written down in the contract write your own framework/functions and built-up on that, while providing basics of it as Open Source on Github Those things can proof your ownership of that code if necessary or at least will benefit you in proofing in to some point.

Yeah. Communication is certainly the most important part. Depending on how you service your clients I this might even be entirely out of line. The second step would be having a proper licensing and contracts between yourself and the customers. This is the only thing, which will help you if there's someone not playing by the rules. Only after that you can look into making it harder to not play by the rules e.g. using license keys or tools with can encode php code like ioncube. Stuff like that can easily backfire though. For me code using ioncube would be a big reason to look for alternatives. Code which talks to your servers (e.g. license code validation) or even more invasive things like analytic tracking can cause problems in tightly locked down server environments, where code is not allowed to connect to arbitrary external services. So it might also depend on your potential customers what of the methods makes sense.

This isn't something that I personally do, but basically it boils down to a couple of strategies: 1. Use some sort of mechanism for validating number of installations. It can be a license key or something else, but basically you'd have to add code that connects to your server to validate the installation. 2. Explain to the client what they are allowed to do and trust that they follow these instructions. Provide a contract or license and make sure that you can prove they've agreed on it, in case you want to take an action based on it later. Personally I would choose method 2. First of all it's a lot less hassle for you (method 1 is basically only worth it if you intend to sell your product to a relatively big number of clients), and second of all whatever protection you add will be easy to override or remove. ... not to mention that if your code sends data to you, you could potentially get into some trouble for that if it isn't communicated *very* clearly ?

I've now came up with this setup which works really well for me: /site/config.php (can safely be committed to GIT) <?php if(!defined("PROCESSWIRE")) die(); /*** SITE CONFIG *************************************************************************/ $config->debug = false; $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; /*** INSTALLER CONFIG ********************************************************************/ $config->dbHost = 'localhost'; $config->dbPort = '3306'; $config->chmodDir = '0755'; // permission for directories created by ProcessWire $config->chmodFile = '0644'; // permission for files created by ProcessWire $config->timezone = 'Europe/Vienna'; // include config file from outside of the repo include('../config.php'); ../config.php DEV (one file for all laragon hosted sites on my local machine) <?php $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER['HTTP_HOST']]; $config->debug = true; switch($_SERVER['SERVER_NAME']) { case 'www.XXX.test': $config->dbName = 'XXX'; $config->userAuthSalt = 'XXX'; $config->installed = 123456789; break; [...] } ../config.php LIVE (one file for each vhost) <?php $config->dbName = 'XXX'; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->httpHosts = ['www.XXX.com']; $config->userAuthSalt = 'XXX'; $config->installed = 123456789; setlocale(LC_ALL,'en_US.UTF-8'); Thx for that ideas @arjen and @jens.martsch!

Or use my migrations module, to kinda get the best of both worlds. The ease of the ProcessWire API with the ability to have migrations run/downgraded as needed.

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