Craig

Not sure exactly what the cause of this problem is here. But if you only need the title, you can do this: $page->categories->title; That is, you do not need to first get the category for the ID and request that page - as it is a page reference field you get the details anyway.

This is what I was thinking of: <?php // Code for SessionHandler abstract class for reference abstract class WireSessionHandler extends WireData implements Module { /** * Initialize the save handler * */ public function __construct() { $this->addHookBefore('Session::init', $this, 'attach'); register_shutdown_function('session_write_close'); } } class SessionHandlerDB extends WireSessionHandler implements Module, ConfigurableModule { public function __construct() { if ( ! isRestApi()) { parent::__construct(); } } } class SessionHandlerDummy extends WireSessionHandler implements Module, ConfigurableModule { public function __construct() { if (isRestApi()) { parent::__construct(); } } } If that doesn't work, there's an attach() function which could be overwritten/extended instead.

I would probably add it to the picture template. Main reason is that it may be easier in the future if you introduce a different page template that also needs favourite functionality.

I haven't tried this - but, it may be possible to solve this by creating two new session handler modules. A 'dummy' session handler for use with your API, and a clone of the Database handler for normal web requests. Your initialisation code for each would detect if it's being loaded via the REST interface or traditional HTTP, and only register the hook into session when appropriate for it to do so. In your dummy handler, all the storage methods would use an internal array/WireData object, and the other one would work exactly like the existing database one.

There doesn't seem to much in there that ProcessWire doesn't already have in one form or another. What, specifically, would you hope an equivalent PW module would achieve?

Hi Spica At my company, I've needed the same functionality so I've been trying to work it into the module. It pretty much works, but I'm not sure if this is the best way to modify the fieldtype module to work like this with a 'virtual' field and multiple selectors - it seems like a bit of a hack. It will also order results by distance regardless. https://github.com/CloudDataService/FieldtypeMapMarker/tree/develop I apologise for the formatting/whitespace diff. Example - assume the MapMarker field is called 'geo', I would search like this to get all 'place' pages where the map marker is within 30 miles of lat/lon 54.97,-1.62. template=place, geo.unit=mi, geo.distance<30, geo.point_lat=54.97, geo.point_lng=-1.62 In the results, you can display the distance like this: // Centre of the search area: $lat = 54.97; $lng = -1.62; $results = $pages->find("template=place, geo.unit=mi, geo.distance<30, geo.point_lat={$lat}, geo.point_lng={$lng}"); foreach ($results as $result) { // Calculate distance between result's marker and our search centre $distance = round($result->geo->distance($lat, $lng, 'mi')); echo "<li>{$result->title} ($distance miles away)</li>"; } ?> Hope it helps anyway.

As a first step, you could try using the SessionHandlerDatabase module to see if that makes a difference. It's included in core, but not installed by default.

Yes, on the Setup > Templates page, you have the ability to Import/Export the templates in the same way as fields. Export then import your fields first, and then do the same with templates. The screen on import will give an overview of the actions being carried out before you commit to saving the changes.

Shouldn't this be wire('config') - with quotes around the config? Also, echo out $path to make sure it is what you expect.

I do. But I always use the same consistent name - which works well a) for me when I come back to a site I built years ago, and b) for other team members at work so they know where to go.

Very nice indeed! Look and feel is excellent

No problem Tom That's definitely an improvement, but personally I think nearly 6 seconds is still a bit long for a query to execute that would be displayed on a page request. I would suggest limiting it to X number of items first to see if that improves it. There may be other optimisations that can be made as well, or caching could be introduced depending on the use case of the data, how frequently it changes or how dynamic it all needs to be.

Is there a specific reason you're running a MySQL query first? Could you rewrite this part to use one PW selector? Such as... template=event_item, shows_relation.date>2015-11-28, shows_relation.date<2016-01-15

WillyC is right. I noticed this too, and updated a relevant issue at GitHub.

Have you checked the copied site using http://isit.pw/? If you update content on your client's site, is it coming up on the copied site; or is the content "as it was" at the time it was copied? Are you able to access the control panel with your known credentials? Is there a chance that the new domain is "pointing" to your client's site? It depends. If the servers are behind a load balancer or caching server, then many websites would appear to use the same IP. It would all depend on the hosting provider's configuration and DNS configuration of the domains in question.

I don't want to really confuse things here now, at this stage, but in this situation I would always recommend looking at everything you already have, and get that working first. Troubleshoot any and all problems that occur. Once that's stable and functioning, then go about upgrading and/or continuing development, saving progress or backing up as you go. That advice is not just relevant to ProcessWire, but whenever inheriting projects of any type. From experience, this minimises debugging and troubleshooting time, and the wondering if a particular problem was there previously, or if it's related to the new environment or upgrades. If any problems in upgrades or development do occur, you've only got one step (the last one you did!) to undo and get back to the last working state. I think using new versions and/or tools, in this situation and in this way, introduces several (unnecessary) points of failure which may not be immediately obvious and would only serve to throw spanners in the works

Was that code being loaded on every page request?

I've been using Pure almost exclusively for personal and work projects for a couple of years now and really like it. I can quite comfortably build lots of things on top of the existing components and have some of my own LESS additions that help out with responsive stuff. It doesn't excel at complex form layouts as much as I'd like, but I've come up with some acceptable solutions for that.

In my _main.php files I typically include a "layout" variation file. This is what you would start with as the main template, but moved outside to allow more customisation and flexibility. Specify a default layout to use in the _init.php file, and overwrite it in your template files as and when necessary. _main.php <html> <head> <style></style> ... </head> <body> <header class="header">...</header> <section class="main"><?php require "./includes/layouts/{$layout}.php"; ?></section> <footer class="footer">...</div> </body> </html> _init.php $layout = 'default'; // specify a layout that would be used for "most" pages (I call mine default) So most sites might have default, home and contact layout varieties as a starting point. A layout would include the stuff that varies between page designs and you would create as few or as many as you need, and call on the variables set by the template. For example, layouts/contact.php: <section class="content"> <p>This is our address</p> <?= $page->body ?> </section> <aside> <iframe class="map">...</iframe> </aside>

Ah yes, that's right! I was somehow thinking that it was somehow scoped in the same way template files are

You should be able to change the last line to look like this: return $pages->find("template=address, created_users_id={$user->id}"); $user is another one of the ProcessWire variables that is available wherever $pages is, and references the current logged in user. It acts like the wire('user') function, but is a variable, which you can use directly in double-quoted strings.

You could use the built-in WireCache functionality

The website for one of the prominent four-letter political parties in Northern Ireland has been powered by ProcessWire for almost two years now. It currently has about 15,000 pages, and serves in excess of 130,000 requests per day running on typical cloud hosting and minimal PW and CloudFlare caching. Not too bad I don't think (on several levels), but nowhere near some of the bigger sites powered by PW by far (going solely from the Showcase area of this forum). Without giving too much away, it's still happily and securely running the PW version that was installed during its development two years ago. There's also been zero maintenance issues to deal with since launch, a lot of which I believe is down to PW itself.

Hi naldrocks98, have you added a valid API key into the settings page of the module? The error and line number suggest that the Mandrill API library hasn't been initialised.

Once the theme has been installed, you can drop this line into your site/config.php file: $config->defaultAdminTheme = 'AdminThemeReno';