DaveP

I should imagine you could count the dropdown items and if there are over a certain number use CSS Columns. Browser support is good (with prefixes) - http://caniuse.com/#search=columns

I don't know - looks pretty good to me. As far as some of your problems - chaining selectors etc., post some specific questions and I'm sure someone will help. It's a good way to learn, but you seem to be doing very well already.

Everything they ^^^ said, plus I love the little 'go back upstairs' animation.

Forgive me if this is a gormless question, but even after Googling, I can't find an actual list of reserved words anywhere. Ryan talks about one here and here, but is it published somewhere?

http://m.bbc.co.uk/news/technology-31907768 That is all.

There's an entry on the CKEditor forum which looks like it should be what you need, although I haven't tried it.

That usually means a 500 error, and a 500 error usually means an .htaccess problem. Which is why I asked this.

Hmmm, so PW is still running the module. Back the folder up and delete it from /site/modules/. That way it can't. Then lets see what happens.

OK, lets try some troubleshooting. Going back to your first post, I assume everything was working once you had sorted the .htaccess RewriteBase thing? Try renaming the folder /site/modules/MobileDetect/ to something else (put an 'x' on the end for example). AFAIK that should prevent the module running, and restore pre module installation functionality. Also, edit the /site/config.php entry to read $config->debug = true; which should give some helpful messages. And take a look at /site/assets/logs/errors.txt to see if that tells us anything.

I think the way the git repository for the MobileDetect module is set up assumes that you are going to do the installation via git commands on the command line. Downloading the zip and extracting it doesn't give you quite the same control, so there are other steps needed. The Error Handling part of the instructions does refer to the same problem you have, but to resolve it, you'll need to manually download the dependencies (i.e. from https://github.com/serbanghita/Mobile-Detect), and extract them to the empty /libs/ folder.

Another factor that could be beneficial is if the old design wasn't mobile friendly and the new one is - Google is now noting mobile friendly sites (and possible ranking the a bit higher) in mobile SERPs.

First of all, welcome grumpy. It looks like what has happened is that downloading MobileDetect doesn't download the library it depends on - https://github.com/serbanghita/Mobile-Detect which, if I understand correctly, should go in the /blah/blah/blah/site/modules/MobileDetect/lib/ directory. Try downloading that and unzip it to the above folder. Fingers crossed, that should make everything work. If, erm, it doesn't, come back here and we'll try something else.

Looks like it should be - https://github.com/adrianbj/ProcessMigrator/blob/master/MigratorAbstract.php Have you installed the modules on a different path somehow?

<update class='very_late'> Just happened across this thread, looking for something else. To finish off the story, I ended up adding another (non-PW) table to the db with phpMyAdmin, and using a couple of hand-crafted queries to access the data. That was probably the best solution in this case, since it allowed me to do spatial geometry stuff on the grid references that PW doesn't currently support. </update>

If you are using CloudFlare, all you need to do is change your CloudFlare config. You don't get true end-to-end https that way, just between the browser & CloudFlare - not between CloudFlare & your site. My blog (see sig) does it that way (and you get SPDY as an added bonus).

PW Dev >= RC in anything else.

The new quad-core Pi 2 is now out.

Aah, I recall visiting an exhibition of Albrecht Dürer prints in France (in Le Havre, if memory serves) many, many years ago (1969/70ish). Anyhow, good job, MuchDev.

Hi doolin, and welcome! <?php $fullpictures = ""; ?> <div id="gallery"> <ul id="navigation"> <?php foreach($page->bild as $image) { $thumbnail = $image->size(150,100); echo "<li><a href='#{$thumbnail->description}'><img src='{$thumbnail->url}' alt='{$thumbnail->description}' ></a></li>"; $fullpictures .= "<div><a name='{$thumbnail->description}'><img src='{$image->url}' alt='{$thumbnail->description}' ></a></div>"; } ?> </ul> <div id="full-picture"> <?php echo $fullpictures; ?> </div> </div> Written in browser, so I hope it works, and you can follow what I've done. Essentially, I've taken the example code from the article you were following, and replaced bits with php. The main difference is, so that I only need one loop, is build the content for the 'full-picture' div (in $fullpictures) at the same time as outputting the thumbnails markup, then echo it later within the html markup. See if it works...

If I understand your question correctly, one option I often use is to have another template for pages that shouldn't be in the main menu. So the main menu selector might be "parent='/',template=basic-page" (showing the pages you mention) and another "parent='/',template=info-page" for a footer menu (Privacy Policy, Cookies etc).

And that is entirely fair enough. Search should always return the 'right results', whether that means 'the most accurate & impartial results possible' (Google? Hah!) or 'what we want searchers to find' (say an ecommerce site), or somewhere in between. I have probably mentioned this here before, but I once wrote the search logic for an ecommerce site for one of the biggest fishing tackle retailers in the UK. One of our major brands was 'Daiwa', but a fair proportion (nearly half) of searchers spelt that 'Diawa'. It would have been stupid for me not to have catered for that exact situation and return what people were expecting to find. (SteveB, it used the Porter Stemmer.)

FWIW we have an extranet app running on PW, the top 4 parent pages having 2657, 8201, 2850 & 1750 children each. (There is also a non-PW db table that has about 1.6 million rows but that doesn't count.) There are a couple of templates that take longer to load than I would be satisfied with on a public site, but that is because of amount of processing going on when they load. The admin interface is no different in performance terms than a site with 10 pages total. There is no caching, as the data are always changing and all users are always logged in.

This should work... <?php $columns = $page->children; $colcount = $columns->count(); $i = 1; echo '<div class="row">'; foreach ($columns as $column) { if($i == $colcount){ echo "<div class='medium-4 columns end'> <a href='{$column->url}'>$column->title</a>"; } else { echo "<div class='medium-4 columns'> <a href='{$column->url}'>$column->title</a>"; }; if($i % 3 == 0) {echo '</div></div><div class="row">';} else {echo '</div>';} $i++; } echo '</div>'; ?> I have some very similar code to yours in a site currently under development, even including a slight variation on the modulo magic, but I was lazy and applied the 'end' class to every column.

Hmm, that would be because mySQL fulltext indexes don't include words under 4 letters long by default. So 'Sri' won't be found. If you have enough control of your mySQL setup, you can change that, probably to include 3 letter words (unless there are any possible shorter words you would need to find), although at the cost of increasing index sizes. (The limit is there for a reason.) There are a couple of workarounds. The easiest is to not search for words under 4 letters long. foreach($keywords as $kw){ if(strlen($kw) >= 4){ $selector .= "Meta_keywords|DMCcontact_Country|DMCcontact_Address_2|DMC_Email~=$kw, "; } } ...which might introduce other undesirable side effects. You could also vary the selector operator based on keyword length. foreach($keywords as $kw){ if(strlen($kw) >= 4){ $op = "~="; } else { $op = "%="; } $selector .= "Meta_keywords|DMCcontact_Country|DMCcontact_Address_2|DMC_Email{$op}{$kw}, "; } (I don't think the curly braces are strictly necessary, but they do enhance readability.) And, of course, this might also introduce other side effects, although my own hunch would be that this is likeliest to work well. I have another method in mind, but it would be a lot of code and might be unnecessary. (It includes 2 searches then combining/uniquing page arrays, and still might not work ) See how you get on with these variations and we'll take it from there.

@teppo, I've got to agree that animated gifs may be making a comeback. We wanted an (intentionally cheesy) animated banner for a site of ours and decided not to use Flash due to lack of support on mobile, so we went with a gif. (When our designer finishes it...) Now to see whether they can be made responsive...