Leaderboard

XAMPP is actually very different. It doesn't give you a UI to manage folders like that, which I prefer. For reference, as it may help others, this is how I have set up my Apache: 1: Create a folder called 'home' in the root of any drive - I use my own partition for this, but you can host your sites wherever you like. 2: Create a VirtualHost in apache\conf\extra\httpd-vhosts.conf: <VirtualHost *:80> UseCanonicalName Off ServerAlias *.local VirtualDocumentRoot "D:/home/%-2+/public_html" <Directory "D:/home/*/public_html"> Require all granted AllowOverride All Options Indexes FollowSymLinks </Directory> </VirtualHost> Basically, this is like a wildcard Virtual Host, and matches example.local and example.com.local. Note: You need to ensure that the module loads with Apache. This line in httpd.conf should be uncommented: LoadModule vhost_alias_module modules/mod_vhost_alias.so As mentioned, I have my own partition for my server files, but you can use whatever drive you like. I'd recommend, however, that you keep your home folder at the root of the drive. Remember to restart Apache once you've done this. 4: Download and install Acrylic DNS Proxy and add the following line to its AcrylicHosts.txt file: 127.0.0.1 *.local Remember to start the Acrylic service. Mine was automatically set to start with Windows, but did not start immediately after installation. If you're on Windows 7, there will be a new start menu entry that you can use to start the service. If on Windows 8, go to the start screen and type Acrylic, and you'll see the short-cut that you can use to start the service. 5: Create your new site by adding a new domain-folder in the home folder created in step 1. For example, create a folder called mysite.com. Then, in that new folder, create a public_html folder. If all is successful, you'll see a directory listing when you visit mysite.com.local in your browser. You might notice that, when you request the domain for the first time, it does take a few seconds, but that's Acrylic doing its cache-magic. Hope this helps, and is useful to someone.

Hi Mike! Thank you for that answer! I really do need to have separate sites for separate clients. As far as 'minefield' I believe the term is to describe an area that is dangerous. I think during the Vietnam War there were mines placed in the ground so that they blew up whenever some unsuspecting person stepped on them. I realize processwire is not a bomb, but that was just an example for how I see a bad situation making a mistake in Processwire. Thanks for your input Pwired, but I need to create separate sites. In the future I may do a multisite so the information you gave me was helpful.

Jumplinks for ProcessWire Latest Release: 1.5.63 Composer: rockett/jumplinks ⚠️ NEW MAINTAINER NEEDED: Jumplinks is in need of a new maintainer, as I’m simply unable to commit to continued development. Jumplinks is an enhanced version of the original ProcessRedirects by Antti Peisa. The Process module manages your permanent and temporary redirects (we'll call these "jumplinks" from now on, unless in reference to redirects from another module), useful for when you're migrating over to ProcessWire from another system/platform. Each jumplink supports wildcards, shortening the time needed to create them. Unlike similar modules for other platforms, wildcards in Jumplinks are much easier to work with, as Regular Expressions are not fully exposed. Instead, parameters wrapped in curly braces are used - these are described in the documentation. As of version 1.5.0, Jumplinks requires at least ProcessWire 2.6.1 to run. Documentation View on GitLab Download via the Modules Directory Read the docs Features The most prominent features include: Basic jumplinks (from one fixed route to another) Parameter-based wildcards with "Smart" equivalents Mapping Collections (for converting ID-based routes to their named-equivalents without the need to create multiple jumplinks) Destination Selectors (for finding and redirecting to pages containing legacy location information) Timed Activation (activate and/or deactivate jumplinks at specific times) 404-Monitor (for creating jumplinks based on 404 hits) Additionally, the following features may come in handy: Stale jumplink management Legacy domain support for slow migrations An importer (from CSV or ProcessRedirects) Open Source Jumplinks is an open-source project, and is free to use. In fact, Jumplinks will always be open-source, and will always remain free to use. Forever. If you would like to support the development of Jumplinks, please consider making a small donation via PayPal.

Hi, Can you also check the error log in /site/assets/ and report any errors here? Also check if you get any javascript errors in the backend Cheers

Can you please let us know what these errors are and what versions were you running on your local install? Did you have any of these problems on your local install? Can you provide a little more information on this? What did you do to get around this? From a strictly technical point, It would be better if you could upgrade your hosted PHP version from 5.3.29 (to PHP 5.4.x, 5.5.x or 5.6x) and possibly have your Apache at the 2.4 branch. I'm also guessing that you already understand that you will never get optimal performance on a Shared Hosting platform. Don't get me wrong, It doesn't mean that things can't work with this configuration. You just need to be aware that there are going to be limitations. Can you let us know what are your load times at different times of day? Are you having this loading problem on different web browsers or OS platforms? Is this the only web hosting company that you deal with? Are you able to load an online dev version of the site on another web host?

@sephiroth: Create three files: page.php, page_logout.php, page_login.php And write something like the following in the page.php: <?php if($user->loggedin()) include 'page_login.php'; else include 'page_logout.php'; ?> What's the problem here?

Apeisa made a module that allows you to run multiple sites with different domains run from single install http://modules.processwire.com/modules/multisite/ But if you mean developing multi sites on Xamp then it simply is a matter of using a subfolder under c:/xampp/htdocs/ for each site with it's own processwire installation and database. Works for me on Wamp. When you upload a finished website you only have to check that Rewrite Base is configured correct for the hosting server.

Hi, and welcome to ProcessWire! To answer your question: yes, that's the way it's supposed to be done. Each website should have its very own installation of ProcessWire. I do believe there is a module that assists in using one installation for multiple sites, but this is only recommended for a single client that has multiple sites, not for multiple clients running on different servers. I'm not sure what you mean by minefield, though. Could you elaborate that for me?

Everybody who has import scripts running as a cronjob, there's this effect that the cronjob is run als guest user. So imported pages via API are created and modified by "guest". This is not nice and can lead to confusion. "What?! How can a guest create this page?" To avoid this and set the current user via API you can do this at the beginning after bootstrapping PW: include_once("./index.php"); /** * Overwrite static user for imports. All created pages will now * have created and modified user set to "importer" PW user. * Otherwise API created pages will have the created user "guest" * ------------------------------------------------------------------------------------- */ $importerUser = wire("users")->get("importer"); if($importerUser->id) wire()->setFuel("user", $importerUser, $lock = true); Only thing is you have to create a new superuser with the name you wish to use for such scripts and replace the name in the script. Now if you run this script no matter from where or with what current user you'll have "importer" as the created and modified user. ----- Note: There's a new way to set system vars like $user via wire(name, value), but this doesn't seem to work in this case in my tests. Cause the user will get overwritten again when creating a page by the current user calling the script. I'm not sure it's a bug or what, so it might be possible in future to use the shorter version of wire()->setFuel(name, value).

I forked the original module and use this fork for a project in development already. In my opinion it would be much more useful if merged into core, so I opened a pull request for it. You can assess the patch on Github, or you can test it using this temporary standalone module version (not to be used in conjunction with the core PagePathHistory module but as an alternative to it). The Page Path History manager module might be helpful in evaluating it. As always, I'd be grateful for any feedback.

Really like the bottom bar on mobile

While it's certainly possible it's not as easy as you may think it is. Passwords are stored as hashes in the database. ProcessWire will never store the plain text password. The hashing is dependent on the salt value stored in the config.php. The salt is generated as part of the installation process and therefore your live installation may have another salt value as the dev one. If this is the case it means all the passwords of imported users would be invalid after moving them. What you can do is to copy the whole users database table and copy over the salt value, too. As long as all hashes of user passwords are generated with the same salt value you can exchange users as you wish. But if you have users in both installations, where the passwords where saved with different salt values, you can not move the passwords over from one installation to another. You would need to change/update the passwords by hand in this case. Everything besides the passwords shouldn't be a problem.

Update: version 0.0.6 In dev branch for now As per this idea, thanks @dazzyweb, added a renderBreadcrumbs() method to render, uh..., breadcrumbs. See documentation in Read Me for how to use For both render() and renderBreadcrumbs(), you can also pass a Page object as the first parameter. This is in addition to the already available ways, i.e. you can also pass a menu page's title, name or id or an array of menu items built from a menu page's menu_items field. Please test and let me know, especially playing around with the options you can pass renderBreadcrumbs(). See Read Me, including comments in the code. These options can be shared between the above two methods. Same goes for the first parameters - e.g. get a menu page and pass that once to both render() and renderBreadcrumbs(). Also added the option to prepend 'Homepage' as topmost breadcrumb item even when it is not ancestrally part of the breadcrumb. Note If you call renderBreadcrumbs() in a page that is not part of the menu items you will get an error if logged in as superadmin but nothing returned for all other users. E.g., say you have the following menu items: Home About Us Products Services Contact Us renderBreadcrumbs() would only work (duh!) if called from the template file of AND viewing one of those pages. This is because the method works by first matching the 'pages_id' of a menu item with the $page->id (current page) and builds the breadcrumb from that. External menu items can be part of the breadcrumb as long as they are not the current item (of course) - which they can never be anyway since clicking on them will load external URLs

Then you should really take a look at the repos of ProcessRecipes on GitHub.

What I do is setup a password protected subdomain on my website for the site version I want them to see. If they need to see what I'm working on (the development "Work In Progress" version) , I push my localhost live via a tunnel and send them the link. As long as the tunnel is open they can see my localhost. I am using Ngrok but there are countless others. Just Google, "localhost tunneling". It definitely made my workflow easier

A possible solution could be to use an other page to select but you show the current Page title. Here's how to do: In the Page field settings use Custom PHP code to find selectable pages type: $p = $page->parent; $p->title = $page->title; $PageArray = $pages->find("template=type-template, id!=$page->id"); $PageArray->add($p); $PageArray->sort('title'); return $PageArray; Then when the field contains the $page->parent, you know that they wanted to select the current page.

Actually, you can do this on the dev branch. Lets assume that cities are children of countries and that is reflected in your page structure (i.e. /countries/france/paris/). Create your 2 page fields (country and city), and configure 'country' as a single page field with "parent" set to "/countries/". Next, for the "city" field configuration, use the "Custom selector to find selectable pages", present on the "input" tab. In that field, enter "parent=page.country". Save and try it out. This works with select, selectMultiple and asmSelect fields (and possibly others), though not yet with checkboxes, radios or PageListSelect.