Craig

Wow, the new Pingdom Website Speed Test result is... amazing Grade D, 10.29 seconds load time, 3.5 MB page size, and 206 (!!) requests.

I think that is a novel way of setting the focus point! But I don't necessarily agree that it should be the only option. I have feeling more novice users/editors would be confused by it not being "specific" enough, as they might not be able to visualise how that appears in the front-end on their news article for example. Unless the pre-defined crop areas - as they exist now - will still show a preview step, somehow? Perhaps I've been thrown by the multiple tiles in the demo? I just really enjoy how, for me and the projects I've worked on, CroppableImage has been one of the best image-related things in PW. It just helps so much being able to specify the dimensions images should be

That's pretty good Pete! Should be nice seeing the data and results and getting the feedback and seeing the differences in a short time

Hi ceberlin. According to the original post, the upgrade was rather important to do. It's different, yes. And it may take a while to get used to. But it's something that needed doing

Hey Pete I have one! In fact, the four of us in the company where I work have one each - we agreed to take part in a three month office wellbeing experiment conducted by a local university. Fitbits were given out to participants, and the academics used the heart rate and sleep data in their study. Once we got them, we became very competitive. Who got more steps this week? Who's walked the furthest this week? We constantly wanted to better our scores, so it has certainly been good for all of us. I think just having the ability to monitor what you're doing and having quick and easy access to that is great. I'd be up for joining a PW group

I, too, have experienced this, but didn't know it was due to SessionHandlerDB (which is usually the first thing I install on new sites).

I'm currently working on an app with something similar, but with potential for a user to have multiple profiles (only one active at a given time). This is how I do it: A user "profile" page is automatically created when users are created. The built-in "created user" field of the profile page is set to the User page - this creates the link. (Needs to have "Allow the 'created user' to be changed on pages?" at template level) A single-choice Page field called "profile" is added to the User template which points to the "current" profile. All of the above things can be done with appropriate hooks. The profile Page field has this custom PHP code for selectable pages: return $pages->find("template=profile, created_users_id={$page->id}"); This allows code like this: echo "You are registered with {$user->profile->organisation}";

Based on own experience as well as observing some topics on here, I would say "yes, but...". The "but" is that certain things need to be done differently, and other things need to be thought about: Code Where will the code that handles the app's business logic be stored and how will it be structured? Bespoke PW modules or use template files? Data The data that you will be storing - what does it looks like? How will it get from the source into the database? What output or reporting requirements are there? URLs Have one or two main entry points and call your custom code? Or have a new Page for most/all URLs. Automatic page name generation Every page has to have a name, and if many pages will be created using the API what is the naming scheme? Re-use admin vs creating custom front-end There's been some talk about this very recently, and the route chosen may depend on: who your audience is, what level of branding is required, and what functionality is available to who. Having said that a lot of the stuff you need from an app framework is already there. Sessions, Users/Permissions, the data layer, output, templating, and other things I can't remember. One thing I've found missing is a robust generic form validation library. I don't like the config format of valitron, so currently using a slightly modified simple-validator. At my company, we've built various SaaS apps and CMSs over the years using CodeIgniter. More recently though, we have used PW where CI may have previously been chosen. Perhaps an interesting example is a recent project where we used only the PW back-end. The branding was changed a bit, but there was no front-end at all. The main function of the app was to generate an HTML5 product showcase/catalogue/datasheet browser, for use on tablets (built with Backbone JS and JSON datasource). The PW admin was perfect for users managing the data. We built a bespoke Process module for the back-end that allowed users to preview and download the HTML5 app.

It's not necessary at all. I just find it handy when debugging to see the output in a more human-readable way Thanks for sharing your examples.

I'm starting to add some structured data to sites too, where relevant, to see what sort of impact it does have on search results. From a technical perspective though, I'd highly recommend using json_encode() over generating strings. Here's one I made earlier (very simple): <?php $socialLinks = array( 'facebook' => 'https://www.facebook.com/BestPageEver', ); $ldJson = array( '@context' => 'http://schema.org', '@type' => 'Organization', 'name' => $homepage->title, 'url' => $homepage->httpUrl, 'sameAs' => array(), ); foreach ($socialLinks as $name => $url) { $ldJson['sameAs'][] = $url; } ?> <script type="application/ld+json"> <?= json_encode($ldJson, JSON_PRETTY_PRINT); ?> </script>

The sessions table doesn't have a 'created' field, so I don't think it's that. The 1292 looks like a page ID. Can you find a page with that ID and what is it? Do you have any hooks that may be attached to login/logout functionality?

In a previous project that needed a specific manual sort, I had some success setting the page field value to a string of IDs in order. $page->items = "1045|1067|1125|1256"; So you could build up a list of IDs in whatever order you want, and then implode() them into the otherPages value when saving the main page.

I think you need to specify the language. Taken from an import script from a multi-lingual site I built, it would be done a bit like this: $def = $wire->languages->get("default"); $chs = $wire->languages->get("chs"); $eng = $wire->languages->get("eng"); // ... $p->title->setLanguageValue($def, $ordernumber); $p->title->setLanguageValue($chs, null); $p->title->setLanguageValue($eng, null);

Oh, I know that, it's fine Not pointing the finger or saying you have to it; it was more of a general thought for the project as a whole, that's all (I do appreciate you taking the time to arrange the Github-ness of it all!)

If this is something that is expected to be installed on a variety of platforms (some of which may not have the ability to change the server setting) then I'd vote for changing the code to use <?php, so it will appeal to a wider audience I know it's not required for this type of project - but the ProcessWire Coding Style Guide says (and is good to aim for):

I would look at using the WireCache functionality. You can find more about that here: https://processwire.com/blog/posts/processwire-core-updates-2.5.28/

This should work: In systemcheck.php, change the short open PHP tags from <? to <?php.

Please tell us what these notices actually say. Having the code is only half of the story here This is probably the behaviour introduced by the slider library that you are using, so it would be a good idea to check their documentation to see if it can be changed or removed.

I've found with the field/template import/export, it is sometimes necessary to do it twice. Once to create the entries (skipping the relationships/family settings), and the second time to apply the correct family settings.

On the source site, go to Setup > Fields, and click the [Export] button at the bottom of the page. Choose your new fields, then click [Export]. This will give you a chunk of JSON-encoded text which represents your chosen fields. Copy the text, and paste it into the same area on the live site - Setup > Fields > [import]. Then do the same for templates if necessary, which will pick up the changes to add those new fields to the relevant templates if they already exist, or create the templates if they don't.

What is the environment like for the sites during development? Local *AMP on a Mac/Windows workstation, or some Vagrant type of setup? And, crucially, do these development versions have the same sort of problems?

From wire/core/ProcessWire.php: $config->ajax = (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest');

When you create users (or any page) via the API, you can pass an option called 'adjustName' and set its value to true. For example, create a page with a name value based on their supplied full name (like others, I would store that in a title field): $u = new User(); $u->name = $this->sanitizer->pageName($this->input->post->full_name, true); $u->title = $this->sanitizer->text($this->input->post->full_name); // ... and other fields $u->save(array('adjustName' => true)); I agree with Martijn Geerts though, allowing (or forcing) users to log in with their email address is good. But user account pages still need names, and if you're not going to generate them randomly and instead use supplied information, then you will need to account for duplicates.

Macaw is joining InVision!

15 March 2016: We no longer require a developer for this project. Thanks for the interest. Hello! My company, Cloud Data Service, are currently seeking an intermediate/experienced developer who can help complete a second phase of development of an online healthcare platform. The website allows visitors to post questions to registered experts in the areas of physical, mental and nutritional health; to engage in real-time consultations with experts using text, video and audio chat; and has a couple of static content pages and a blog. Site is ProcessWire 2.7, payments are handled via Stripe, and real-time WebRTC chat uses a Backbone/Marionette JS interface with Pusher and Twilio services to help. The second phase is likely to include a discussion forum, simple appointment setting between users, more front-end pages for expert user types (reducing load on CMS admin user), and some other minor features/tweaks here and there. We use a Trello board for project management and have good communication with the client via Slack as well as Trello. Ideally we'd like someone based in the UK but can make exceptions for the right person, and would work on day/half-day payment terms. Please contact us via the website or email hello@clouddataservice.co.uk for more details. Thank you!