BFD Calendar

I've spent weeks building a new ProcessWire website for the school where I work. Now they finally agree to put it online, they tell me they have a Windows 2008R2 hosting server with IIS 7.5 web server.... No .htaccess and no mod_rewrite, only URL rewrite by web.config. Does this mean I can throw my weeks of work in the dustbin?

It definitely works now for me. I needed a few (manual) upgrades before it finally worked but I can imagine all hiccups are solved since 2.6.etc.

I tried to match them by ID but couldn't get that to work at all — probably my inexperience. And yes, all pages are active in both languages.

The menu part works fine, it shows the titles of the programmes in English and Dutch when switching languages. For some reason the "$features = $pages->find("template=students, stu_programme=$page->title, sort=title");" doesn't match the Dutch page title in the URL to the Dutch title of the 'programmes' pages, like it does for English.

I have a submenu to show only students from specific programmes on a general list of students. The submenu works and shows up in English and translates into Dutch when I switch languages. But when I choose a subcategory it only shows the list in English, not when I switch to Dutch. This is the submenu code: $programpage = $pages->get("/students/programmes/"); $children = $programpage->children; foreach($children as $child) { $class = $page === $child || $child->children->has($page) ? " class='on'" : ''; echo "<li><a$class href='{$child->url}'>{$child->title}</a></li>"; }; Here I make the list for the programmes: $features = $pages->find("template=students, stu_programme=$page->title, sort=title"); 'stu_programme' is a page field and the pages all have titles in English and Dutch. URL 'mekano/en/students/programmes/bachelor-of-architecture/' finds the list of Bachelor students, while URL 'mekano/nl/studenten/programmas/bachelor-architectuur/' finds nothing... Where am I going wrong?

From a few tests I did the option ", id>14950" was definitely the best. As soon as the script has to search through over 2000 pages it bounces on several '30 seconds' errors. And it's definitely better to break down .csv imports to about 200 and run the script before it chokes.

Wouldn't it be better – in my case – to have the script search for pages where template=student and languages are not active and then set them to active? Otherwise I have to add the 'languages_done' and store a 1 in all the pages that are already there. And maybe if it doesn't find any it wouldn't slow down anything either, except of course the time of running a useless script.

Or if you imported a lot of pages from a .csv file. I imported over 500 'students' - in several batches - that needed to be available in two languages. When importing from .csv pages are only published in the default language, which is why I used the code. I keep the 'ready.php' with code commented so I can run it after importing some more pages from .csv. Apparently the page can be used for other purposes as well but I'll leave that to the experienced users here.

That was indeed what I had: // SET ALL LANGUAGES ACTIVE SCRIPT $pages->setOutputFormatting(false); $pag = $pages->find("template='students'"); foreach($pag as $p) { foreach($languages as $lang) { if($lang->isDefault()) continue; $p->set("status$lang", 1); $p->save(); } }

Well I narrowed everything down to ProcessWire itself and found out what was happening.... I had been importing a lot of pages from .csv files that needed to be available in all languages. For that somebody here advised me a ready.php file with a 'set all languages active' script. That worked fine, but now it turned out it was making ProcessWire more sluggish by the day. Commenting everything in the ready.php file made ProcessWire jump again like a young horse.

PW 2.6.18 - PHP 5.6.7 cache module off - Apache port 8888 - MySQL 5.5.42 port 8890 - using MAMP Pro 3.2.1 - MacBook Pro OSX 10.10 or Apache/2.2.29 (Unix) mod_wsgi/3.4 Python/2.7.8 PHP/5.6.7 mod_ssl/2.2.29 OpenSSL/0.9.8zg DAV/2 mod_fastcgi/2.4.6 mod_perl/2.0.8 Perl/v5.20.0 configured

@FrancisChung, checked but I don't see anything special or different in the last two weeks, which is when the slowness started. Plain html pages load fast so I suppose either MySQL or PHP are the culprit.

@ cstevensjr, yes I checked that post and searched the forums but found nothing really helpful for Mac localhost. @FrancisChung, will do that tomorrow and maybe post when there's anything remarkable to be found. Thanks.

Since a few days without any system changes, updates or whatever Processwire is running very slow on my localhost:8888, it takes almost a minute for any page to load, including admin pages. I'm using MampPro on Mac OSX 10.10. Other (html) sites run fine and I'm just working on one PW site. Anybody has any idea where to look?

sforsman, thanks but that didn't solve the problem. Tried with different browsers from different locations on different computers... I have other sites with same provider and same config.php setup and no problem there. It remains a mystery to me. echo ini_get('session.cookie_lifetime'); says 86400

Nobody?

Worked like a charm with ready.php

Great to learn something new and very useful again. School is on Monday so I'll try it then. Thanks!

The Great Ryan solved the problem in PW dev 2.6.18. Hurray!

I'm importing students names for a school website, so only the 'students' template needs to be active in all languages. I can find that in the script but my next question is where I can find the page-creation API script to add the code.

When importing pages from a csv file with ImportPagesCSV they are only active in the default language. Is it possible to make them active all at once in all languages, on import or afterwards? I tried ProcessBatcher but it doesn't support this. Maybe someone has another solution...

And after another upgrade to PW dev 2.6.17 the problem still persists. Very annoying.

The $config->sessionExpireSeconds in config.php is set to 86400 but still I have to log in as admin after about 10 minutes of inactivity. Any other hidden corners where I should look to set this right? $config->sessionChallenge is set to true. $config->sessionFingerprint is set to false.

The problem persists in PW dev 2.6.15.

Yep, tried that too.