Craig

Hi bracketfire, thanks for your comments! I'm pleased you're finding the module useful. The HTTP_USER_AGENT is used in conjunction with the IP address for "fingerprinting" - adding additional security checks against the client. It utilises the same methods as the main ProcessWire session class. In the first instance, I should probably update the fingerprinting code to use the user agent value only if its present; and additionally, look into changing the init() function to not do anything on the command line. I'm not sure that there will be one true way to detect with absolute certainty CLI vs HTTP, as this SO thread discusses, but php_sapi_name() looks the closest. It's probably no use running this module when in CLI mode anyway, so this is something I will look at. Thanks again! Craig.

Yes it is! Oops - too quick, didn't read fully

Check site/config.php - there is an entry for timezone about line ~24: $config->timezone = 'Europe/London';

I implemented a similar thing a while ago and ended up with the code below. I think it was pieced together base on some previous code we had lying around at the company, and I'm not sure why the distance value is so precise at 8.047. It's not a perfect circular distance either, but it seems to work for what was needed at the time. // $lat and $lng should be float values of the location to search $distance = 8.047; //in km $radius = 6371; // earth's radius in km = ~6371 // latitude boundaries $maxlat = $lat + rad2deg($distance / $radius); $minlat = $lat - rad2deg($distance / $radius); // longitude boundaries (longitude gets smaller when latitude increases) $maxlng = $lng + rad2deg($distance / $radius / cos(deg2rad($lat))); $minlng = $lng - rad2deg($distance / $radius / cos(deg2rad($lat))); $query = "coords.lat>=$minlat, coords.lat<=$maxlat, coords.lng>=$minlng, coords.lng<=$maxlng"; In that code, 'coords' is the mapmarker field.

In the past I've worked on an OpenCart site and used vQMod to add new functionality. I don't think it's particularly great Personally, I think that is a very fragile method of working around the problem of not having a system that is open and easy enough to enhance with the standard language tools and functionality available to us as developers. I don't see it is a long-term solution to poorly-designed application architecture, but as a "best effort" fix for working that way when you absolutely have to.

Thanks for the feedback teppo! Those are definitely very good points. I had forgot about index.php, mainly because I only ever having to upgrade that once or twice since I've started using ProcessWire. But I think that will be easy enough to add in. .htaccess is a different issue altogether, with user customisations being quite likely (I know mine are always different). I like your idea of diffing the current one with the new one and providing a notice about it. Automating the replacement or merging of that would cause more problems than it's worth The way my hosting is set up wouldn't allow for a single shared wire directory because the sites are all separate and on separate hosting accounts. But if I was running my own server then it's certainly something I'd consider.

Hello! I've now got more than a handful of websites running ProcessWire - some running from master and some on development. As Development branch sometimes moves rather fast and I want to keep certain sites up to date with those changes, I wanted to make the upgrade process a bit quicker and smoother if I'm going to be doing it more often. I made a quick and dirty bash script to handle this for me and thought I'd share it for others to make use of. I've only tested it on the hosting platform I use - Vidahost Cloud - which is Linux-based and has Git installed. So you'll probably need that sort of environment too Get it here: wire-upgrade.sh. The basic concept is as follows: Clone ProcessWire dev or master branch from Github to a temporary directory. Move the wire directory from the repository into the current directory named wire.new Rename wire to wire.backup.... Rename wire.new to wire Remove the temporary directory from step 1. The script should be ran in the site's root folder - the same level as the "wire" directory. Just specify which branch you want to upgrade to (master or dev) as the parameter (see comments at the top of the script for an example). My shell scripting skills are a bit on the rusty side these days, but I think I've got most bases covered. Any feedback, improvements, comments or suggestions are very welcome

Yet another new rich text editor I came across today - Trumbowyg.

Excellent! You're welcome

Hi Tom! There are indeed several ways to manage this! Your first choice to set the visibility to hidden would be handled by creating a custom module. Your code would hook into the page creation/page save events, check the template for "event", and set the page to hidden. There are several modules in the Modules directory that will hook into the same place which you could look at for examples on how to do it. One that springs to mind is the Date Archiver module. I don't use MarkupSimpleNavigation, but I think it would be able to support what you want somehow. If you check the documentation, it seems you could do it one of two ways: 1. Use the "selector" configuration option. You might be able to specify "template!=event". 2. It looks like you could use "nav_selector" to customise the output for that section of the website.

What sort of hosting are you using, vxda? I sometimes come across this on Cloud hosting where shared NFS storage is used. Not just in this module, but also the core PW modules cache file, before that was moved to the new DB-backed WireCache class. I've had success when removing the LOCK_EX parameter on file_put_contents calls. For this module, it's in two places - lines 464 and 111.

It might be worthwhile contacting tsohost to see if they can identify the cause or route that was taken.

I use Chrome as my main browser; and when I need to do account or session based testing I usually head to Incognito mode as well

Thanks Dave. That's not something that I've looked at specifically - I copied the parameter values from elsewhere in ProcessWire - and the domain one is just set to null. setcookie($this->get('cookieName'), $value, $expires, '/', null, false, true); I haven't been caught out by this issue as I've always set up individual hosts for each site I work on; but definitely something to be aware of. It would be relatively easy to add a configuration field to the module for a user-specified cookie domain though, if it was required

I would create the download section first - arrange them using categories, tags or the tree - whatever makes sense for the site structure and content. Then create a new Page reference field which will allow the selection of videos from the download area, which you can then add to your product templates. This means there is no messing around with TinyMCE (which could be an administrative nightmare to maintain) and you will have complete control over the output/markup of the video listings.

You're welcome. Thanks for the feedback DaveP!

Nope, you could definitely do that. I've added some detail to your example above, does that help? Just add a new "link" page (using the link template) for each additional page you want to link to in the menu. Each link page will give you the option of specifying which site page to link to using the "link" Page fieldtype.

I would create a new template with Page field which could be used for those pages. For example: New template: link Fields: title, link New field: link Type: Page Input: PageListSelect When creating custom page links in your page tree, just use the "link" field to browse to the destination page. You will then be able to access the destination page in the code: <?php $children = wire('pages')->children(); foreach ($children as $child) { $url = $child->url; $title = $child->title; if ($child->template->name == 'link' && $child->link->id) { // Access the "link" field on the child page to get the destination page. $url = $child->link->url; // Optional: use the linked page's title? You decide! $title = $child->link->title; } echo "<a href='$url'>$title</a>"; } ?> Using this method, you could even add a URL text field to the template if you wanted to link to places offsite as well.

You may have to modify a value in .htaccess. Open the .htaccess file in the ProcessWire directory, and look for RewriteBase for commented-out examples. Change it to : RewriteBase /!soulsliverCMS/processwire/ As onjegolders mentions though, the exclamation mark might be a problem in some instances. If possible, remove it to see if it makes a difference.

I'm wondering if it would be worthwhile wrapping that declaration in another check, inside the current mod_rewrite check? <IfModule mod_env.c> SetEnv HTTP_MOD_REWRITE On </IfModule>

In this situation I would either cache the list of years using something like MarkupCache, or use the Date Archiver module to have an additional layer in the page tree for the years, which would be quick and easy to loop through.

Yes, there is a problem somewhere - on Windows, I too get the "old" admin theme when trying to use Modesta. Removing this line in /wire/core/AdminTheme.php allows it to load, however. if(!$this->wire('page') || $this->wire('page')->template != 'admin') return;

You can access the user template by going to the Admin > Templates page, click the Filter section at the top, click Show system templates, and then Yes. A new group of templates will be shown (with the "system" tag) - user is one of them. Click that to view the user template

Yes, you could - ProcessWire users are just pages with template of "user". Because they are pages, it means I can also do things like this, if I just want to allow users of a certain role: template=user, roles=member

Another quick update to this problem - in that it should not be a problem any more! Ryan's changes in ProcessWire 2.4.5 (commit) has moved the modules cache file into the database using a new cache module - removing the problem caused by the file not getting written properly in certain environments. Thanks Ryan!