Craig

Thanks cstevensjr, Can Yes, it's using Pure CSS. The layout uses the responsive grid units (pure-u-*) nested as deep as necessary within rows (pure-g-r) to get the different parts to fit together and align properly. If you use the browser developer tools to inspect the DOM you should be able to see how they're all set up. The header and footer are just wrapper DIVs with the row (pure-g-r) inside.

Hello I've been interested in the Google Street View time machine feature since it was released, and decided to start collecting/documenting scenes that have changed in some interesting way (to me) between the capture dates. Changes It's nothing really fancy - just listing items with images, tags and maps. Posting new things is easy and frictionless, which is good because the process behind getting the images in the first place is the time-consuming part! Modules used include All-in-One Minify, MarkupRSS and MapMarker.

I do believe a new standard for screencasts has just been set!

If you have little to no web development skills, WordPress is probably best platform for throwing together pre-made themes and plugins to create something resembling a website or blog that is relatively straightforward to manage. But it won't necessarily be "good." Scalability, extensibility, customisation, performance, suitable page size, code quality, upgradability, integration... many things that are an afterthought, difficult to accomplish, or require even more mediocre plugins to address. I can't think of any projects where I would use WordPress over ProcessWire.

I think something like this would work in your .htaccess: Order Allow,Deny Deny from 180.76.5.0/24 180.76.6.0/24 Allow from all

Why not? Almost everything in ProcessWire is a page, so this would be a good way to go. Especially if the profile information will contain more details/fields than a plain user template. I might approach it like this: Create at least two templates - member and company. Create and add your user detail fields to these templates as appropriate. Create a Page reference field with a name like owner. This should be configured to reference template=user at the very least. This is the way user detail pages would be linked to actual user accounts. When a user registers, you would create a new page with the template as either member or company. Like this: $profile = new Page(); $profile->of(false); $profile->template = 'company'; $profile->title = 'Acme Widgets'; // but most likely from sanitised POST data $profile->owner = wire('user'); // this links the new page to the logged in user $profile->save(); You can find the user profile info like this: $profile = wire('pages')->get("template=member|company, owner=$user"); I think this method has a few benefits: You don't need to modify the core user template. One user account could potentially manage multiple profiles if you wanted this to be the case in the future. A profile owner could be easily changed to someone else if necessary. Profile types can be easily changed later. Profile type can be identified by its template which should make it easier to differentiate when viewing or searching. The code examples above haven't been tested, and are just an example of how it could be used You could even mix this in with diogo's suggestion - still have a template and page with URL segments, but using different templates for the profile information.

Hari KT, you may be interested in testing the module I have been working on to deliver this functionality - LoginPersistent.

Thanks Wanze! I really wasn't sure what the best naming format for this was, so I'm definitely open to changing it to something more suitable Edit: I have just discovered this post - How to present your module - which confirms that Process definitely isn't needed here. It has now been renamed to LoginPersist. If anyone has already installed it, please uninstall, remove, and install again

Hello! About the same time Hari KT asked about "Remember Me" functionality, I identified this as a feature I wanted to implement in some sites under development. Having done this twice before (in CodeIgniter) and based on previous research, I decided to build a ProcessWire module to provide this feature. So far, I have developed and tested this on ProcessWire 2.3. I would welcome any feedback, comments, suggestions and problems from people who are keen to use this. To re-iterate the readme, this module allows users to remain logged in across browser sessions. The module can operate in two ways:Automatically. No code changes, but users do not have a choice. Manually. The module must be called from a site's custom code. Options can be changed in the module configuration page. Enable fingerprinting (IP address and User Agent) as an additional security check. Limit the persistent login functionality by role. Set the name and age of the cookie. Sets an identifier in the session when a user is logged in via a persistent login cookie. This should be used to control access to sensitive information and actions within a site's custom code. Clears login tokens when a potential theft has been identified. Updated: LoginPersist on GitHub

Yes. One of my company's healthcare products has users on IE6 and IE7 (those account for about 12% and 25% of traffic respectively the last time I checked). There are other users on other browsers too, but we do have to support them all. In our case it's not particularly government or local authorities either - it is the remote desktop systems supported and maintained by private IT companies. For public-facing websites though, we would typically support IE8 upwards, and try to make it look half-decent in IE7 if it's not going to take too much effort.

What I would do, is replace the Save button with two separate buttons: "Save (Major)" and "Save (Minor)". Accent/highlight these as you see fit. The click action of either one would be caught by javascript, where you can then add a hidden field to the page to set the value of major or minor. Then submit the form. The module would hook into the save process to do the actual incrementing of the field value. The action is clear either way. There are no number fields for them to screw up (which they would, somehow) No annoying modal box gets in the way.

I'm not sure I'll be any help to you here. My company is based in the UK and only use UK hosting, which are probably not the right thing to recommend in this case

DigitalOcean have also had their fair share of security-related issues, the most recent being document here - DigitalOcean Security Disclosure 2014-03-30: Not destroying droplets securely, data is completely recoverable. teppo is right - if you don't have the in-house resources (skills and time) to manage a server yourself and all of the issues that it brings - then a managed provider who can deal with all of that is the next option to consider.

Hi Pete... I did something similar a while ago to sync active directory users with a mail server, using adLDAP. The unique ID was derived from the objectguid. Like this: // Define the fields we want to get $fields = array('sn', 'givenname', 'objectguid', 'description', 'displayname', 'useraccountcontrol', 'lastlogon', 'profilepath'); // Retrieve user info from AD $userinfo = $adldap->user_info($username, $fields); $id = bin2hex($userinfo[0]['objectguid'][0]);

That sounds like a really interesting project Some measures you can consider: Session inactivity timeouts. Force regular password changes and/or use 2-factor authentication. Use SSL. Ensure users can only access the data they are allowed to. Not just through interface options, but URLs as well. Look at the hosting infrastructure. Credentials to access it. Who has access? What about your provider? Where is your database is stored? (Shared hosting? Easy to guess credentials?) Look at how data is imported and exported within the system. Is it possible to bypass any validation or auth checks? Forms. They should definitely be using CSRF protection. Can user input be overloaded? That is, can I submit additional form values that the system doesn't check or expect, but still get saved to the DB. Logging. Log as much as you can in order to provide an audit trail. It is guaranteed that somewhere down the line, someone will ask the question "When did this record change to this value and who made the changed?" Backups. Hopefully the data will be backed up. How easy and quick can this be restored? What granularity? User education. Some users may need it explaining to them that sharing usernames and passwords, or writing them down, is not good practise. There are probably some additional things - that could start getting into the realms of penetration testing - but that's a summary things I can think of in a short time

Hello! This is a website for another local group/hobby I'm involved with. I've been responsible for managing their website for about 10 years now, and it's seen a few revisions over that time - from a simple static site, through several other CMSs, and now ProcessWire. There's only really me who manages the content, but when I do I need it to be quick and easy to do - and of course that is now possible For the past 2 years or so it's been powered by WolfCMS. This version is a fairly responsive design (might need some minor adjustments here and there!) that has only had some small tweaks since the last version, as it works quite well. The only modules used are All-in-One Minify and TextformatterVideoEmbed. Visit: Bishop Auckland Radio Amateur Club. There's another website I manage for the club too (Railways on the Air), which will also get the ProcessWire treatment when I get round to it

I'm not sure if that's going to help or hinder your learning journey with ProcessWire... Enjoy! Yes, it's possible... one of the best methods is to just work though things slowly, one bit at a time. Ideally when you have enough time to take things in and generally "mess around" with your install. Then it should all start falling in to place.

That's true Let me give you a bit of detail on how I created this photo section. There are two main templates - photos, and photos_index. They have the following fields: photos_index (fields: title, headline, summary) photos (fields: title, summary, photos) "photos" is a standard "Image" field type which allows multiple images and descriptions. The page tree looks like this: Photos (template: photos_index)2 Star March (template: photos) Easter Training Camp (template: photos) ... Each gallery/album/collection/folder of photos (whatever terminology you're most comfortable with) is just a page that uses the photos template. Within that template, there is an image field that will hold all the images, with the ability to add a description for each one. Nothing will happen on the website without the code - the code that takes the data from the page and transforms it into nice, clean HTML markup for the browser to interpret. View the code for both of the templates. The photos_index template (the parent page, remember) gets the child pages (each album/gallery...). For each one it finds, it will create the link to it, and use the first image from the photos field of album as the thumbnail. The photos template works in a similar way, but one level deeper. First it shows the album's title and summary content if present. Then it gets all the images added to the "photos" field of the current page. For each one it finds, it will create a link to the large size, and display a thumbnail. At the end, there is some javascript that tells the Photoswipe jQuery plugin to activate. Does that help you get any further towards what you're after?

Pages within the CMS don't have a .html extension, so you are right to remove that. Your next try with just the name ("portfolio") is close - but when you are on another page, it is treated as another directory - so it assumes you want that file (portfolio) in the current directory (site-map). Change the topNav links to look like this: <ul id="topnav"> <li><a href="<?php echo $config->urls->root ?>" class="home"><span></span></a></li> <li><a href="<?php echo $config->urls->root ?>portfolio/" class="portfolio"><span></span></a></li> <li><a href="<?php echo $config->urls->root ?>services/" class="services"><span></span></a></li> <li><a href="<?php echo $config->urls->root ?>about/" class="about"><span></span></a></li> <li><a href="<?php echo $config->urls->root ?>contact/" class="contact"><span></span></a></li> </ul> <!-- topnav ends --> It uses the $config API variable to retrieve the site's root URL, and then just appends the name of the page you want to link to.

Thanks for your point of view and feedback, Max I do agree that having documentation that is more task oriented could really benefit newcomers and give them a boost when getting started. That is quite a large undertaking though, because with PW, there is no one single way to do most things that people want to achieve. I think it would be more of a recipe book of sorts. Starting at the top with "I want to do X with ProcessWire..." and then breaking those down further - with one or more suggested methods to try in tutorial-like formats. Some of the content in the Wiki is OK at this - and will use one way of doing things which you can then use the same approach to your own site or to similar parts of your own site. But there is always room for improvement and hopefully those of us with the time and skill do so, will help

One way I would look at setting this up would be to create a new "Page" field with a name like sidebar_links and the "multiple" option used. Add this to the templates that your pages use. When editing pages within the site, the sidebar_links field can be populated with any links of the admin/author's choosing. In your templates, you can get the sidebar_links field and use it in a couple of ways: Search up the page tree, from the current page, until you find a sidebar_links field that has items in it and list them all. Get all the entries from the sidebar_links fields from all the pages in the current tree and display them all in one or separate lists To ensure the top nav links don't appear in the sidebar, I would create an array of those somewhere. Use that array to build the top nav, but also to check if any of the rendered sidebar links appear in it. If they do, then skip that link and move onto the next. You could also append/prepend the current or parent pages, depending on your preferences. You can also get the current page's siblings rather easily if you wanted to include those too. I use a variation on this approach for the collection of random pages like About, Policy, Terms, FAQ, Contact... which may not fit into a single parent within your existing tree, but need to be displayed in that one place, can easily be updated in the CMS, and will automatically reflect title/URL changes.

I haven't done this before, but if faced with this problem - I would attempt to have child pages using a template of "order_items", instead of repeaters. Yes, there would be lots of them (eventually), but it shouldn't be a problem as you know where they are and hopefully add the correct fields & data to them.

This functionality already exists as well - albeit not at that stage of the process On the Fields page, there is a column in the table for "Templates", which has a number in it next to the fields. Click the number and it will show you the templates that are using it. This actually goes to the templates page and activates the "Filter" menu at the top.

Did things get a little grizzly after that exchange?

This isn't the first time they have been noted for inaccuracies. In fact, there is a whole cause behind it - W3Fools. Usually, such things are better catered for by pages on Mozilla MDN.