BFD Calendar

Thanks Horst and Ryan. My coding skills were probably the culprit in all this. Just weird that the problem suddenly appeared after upgrading. Maybe a coincidence, but I'm glad I learned something once again. Anyway, I'm up and running PW 2.7.2 again!

Looking further I notice a difference on how PW saves the links... https://upload.wikimedia.org/wikipedia/commons/5/53/Peter_O'Toole_-_1968.jpg becomes https://upload.wikimedia.org/wikipedia/commons/5/53/Peter_O%27Toole_-_1968.jpg while https://en.wikipedia.org/wiki/Peter_O'Toole just remains https://en.wikipedia.org/wiki/Peter_O'Toole But again, PW 2.7.2 does it differently...

I put the site back to PW 2.6.18 and the links and images are working again. http://www.birthfactdeathcalendar.net/people/otoole-peter/ Code for the photo: // PHOTO if(count($page->bfd_people_picture)) { $images = $page->bfd_people_picture->getRandom(2); foreach($images as $image) { $thumbnail = $image->width(300); echo "<div id='images'><img class='photo' src='{$thumbnail->url}'></div>"; } } elseif($page->bfd_image_from_url) { $webimage = $page->bfd_image_from_url; echo "<div style='max-width:300px'><img src='{$webimage}' align='right' style='width:100%; height:100%' /></div>"; } else { $homeimage = $homepage->images->getRandom()->width(300); echo "<div id='images'><img class='photo' src='{$homeimage->url}'></div>no photo available"; } Input in the 'bfd_image_from_url' field is https://upload.wikimedia.org/wikipedia/commons/5/53/Peter_O%27Toole_-_1968.jpg Code for the Wiki link: if ($page->bfd_url_wiki) { echo "More info on <a href='{$page->bfd_url_wiki}' target='new'><b>Wikipedia</b></a>"; }; Input in the 'bfd_url_wiki' field is https://en.wikipedia.org/wiki/Peter_O'Toole Both fields are URL fields. No text formatter for image and HTML Entity Encoder for Wiki link, Local/relative = yes, prepend root path = no for both. I admit I'm by far not the best coder and of course I'm most willing to improve or change whatever is necessary to make things work. All I was saying is that this works fine in PW 2.6.18 and it doesn't work in 2.7.2 Thanks for help.

Ryan, I'll make an example on two sites that are running on different versions of PW with same input and output. I'll post it here when ready.

I'm sorry, but it worked fine from PW 2.0 to 2.6.18 at least for the past two years or so. Since 2.7.2 it doesn't work anymore. Or are you telling me that I have hundreds of links to pages and images that actually never worked? I do check my pages to see if they do what they are supposed to do.

Can we expect a solution for this soon? Apparently PW 2.7.2 has changed all the URLs with an ' in a way that they don't work anymore. An old Peter O'Toole Wikipedia link doesn't work anymore, also the link I use to a Wikipedia image doesn't work anymore. http://www.birthfactdeathcalendar.net/people/otoole-peter/ I also hope the fix will repair all the URLs since finding every one with a ' would be a considerable amount of work.

BitPoet, good about the bug and module. But what I like about ProcessWire is that it keeps everything simple, and I don't want to use too many modules. Having URL fields should be a basic thing for which we don't need an extra module. Also, things that worked fine in all previous versions shouldn't move to a module all at once. I have about 2000 Wikipedia URLs in as many different pages, see them go astray would be a little disaster. Ps. Sinéad's birthday is today, but Nothing Compares to PW.

HTML Entity Encoder is on. Allow relative/local URLs is "yes". Allow internationalised domain names is "yes". Allow single/double quotes is "yes".

That keeps the URL complete, but now the link is cut off at because in my template I call for echo "More info on <a href='{$page->bfd_url_wiki}' target='new'><b>Wikipedia</b></a>"; So there's a bit of a problem with double and single quotes.

I'm getting an 'Error found - please check that it is a valid URL' when I enter ""https://en.wikipedia.org/wiki/Sinéad_OConnor" automatically but then the "O'Connor" becomes "OConnor" and the link doesn't work. Didn't happen in previous versions of PW. Ps. Not that I'm such a big fan of Sinéad but I'm updating births in my BFD Calendar and hers is coming up in a few days.

I installed a new ProcessWire site from grabpw.php and then added templates and replaced database with a local backup where I developed the site. The homepage shows up with menus and languages. I can see and edit all the pages in the admin interface but on the site only the homepage is available. I can switch the language on the homepage. All other pages show a blank page. Must have missed something.... Maybe someone can tell me what. http://www.mekano.info/

Well, they don't want to let me install ProcessWire because of security options. The server is a 'non-dedicated environment' and ProcessWire has no possibility to change write permissions on the Windows server. So they don't want to have the whole site write permissions. I could send the files by SFTP and then have someone else make or change the settings. Seems not very practical to me. If anybody has more ammunition for me to try and convince them, let me know. I already directed them to the links mentioned above. Otherwise I'll just use a cheap hosting service and do my thing on my own.

Phew! Thanks all. I'll let you know when it's online.

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.