teppo

Possibly just a slip, but.. you didn't mention A List Apart there? Other than that, http://www.zeldman.com/, http://davidwalsh.name and http://addyosmani.com/blog/ are quite entertaining... oh, and http://blog.ponyfoo.com/ of course! Too much good stuff to keep track of nowadays but that's what Twitter is for.

OK, that didn't work quite as planned -- too much content there obviously. Was it actually cut in the middle like that or did the part with that URL you're trying to output show up too? If it did, it'd be nice to see that and a few lines around it, just to make sure.. What I was looking for was what your $outBody variable exactly looks like at that point -- ie. if it has PHP code, such as <?= ...whatever... ?>, in it. In that situation simple echo wouldn't eval the code and it would print out as-is. @Soma: that shouldn't be needed. PHP echo and short echo can both handle ternary operator just fine.

Short excerpt from search.php of Foundation site profile: // if the above doesn't find anything (perhaps due to MySQL minimum word // length or stopwords), switch to non-indexed phrase match if(!count($matches)) $matches = $pages->find("title|body%=$q, limit=$limit"); This is actually pretty nice idea -- use faster method first and only if it seems to fail switch to slower one. Don't know how much difference that really makes, but still. Also: there's a pager now, which is pretty obvious improvement already

I may be a bit tired here, but I can't see how that was even related to what I asked above Let's try this instead: insert <?= var_dump($outBody) ?> right before your "$partial->set('text_area', $outBody)" row and paste it's result here. This should pretty much show if I was on the right track or not.

This all seems a bit confusing, so I'm not really sure if I'm even on the right track here, but still: is that first piece of markup + PHP you posted actually a variable value, ie. your variable contains stuff like "<p><?= ... ?></p>" etc.? In that case the problem would be that just echoing out a string containing PHP won't (and shouldn't) evaluate that PHP as code. You'd have to use eval() for that, which on the other hand is something I'd strongly recommend against. Anyway, if that's the case I'm sure there are a ton of better options -- but before going any further I'd like to confirm if my guess was anywhere close to reality?

Selector operator "~=" means that at least one of the fields you've defined (teaserBody, contentHeadline, contentBody) has to contain all specified words. Order doesn't matter, though. Are you absolutely sure that's the case? This could also have something to do with either stop words or length limitations, so you might want to test it with longer words and/or change selector from "~=" to "%=". This is a bit slower, but so far I've been using it pretty much everywhere without any severe performance issues.

@Hieu Do: there was some discussion about Apache Solr a while back, though I don't think anything concrete came out of it (not yet, at least.) Most of the modules publicly available are listed at the modules directory, so you might want to check that out at some point.

@videokid, take a look at _main.php: <?php if($page->summary) echo "<meta name='description' content='$page->summary' />"; ?> <link rel="stylesheet" href="<?=$config->urls->templates?>foundation/css/foundation.css" /> String interpolation only works when variable is in double quotes and in those cases it's just easier (and source-wise more readable) when single quotes are used instead of escaped double quotes (\"). On the other hand, elsewhere it just makes sense to use double quotes

Short version: use pages for your tags and page type field to select them. In field settings (tab "Input" to be precise) there's an option called "Allow new pages to be created from this field?" -- this is how you can let your users create new tags on the fly. If you need additional details, I'm sure others will fill in those for you, I'm in a bit of a hurry right now..

One useful thing to do when having issues like this (if you haven't already done it) is to check your site log files (/site/assets/logs/errors.txt) and - if the site isn't public yet - try turning debug mode on. This could reveal something about the issue. What @horst is referring to sounds like it could be related to blowfish support.. but that should throw an exception which in turn should be difficult to miss. Anyway, that could also be related to the issue here. PHP version info would be helpful to make sure if that's really the case. And ultimately, as @horst already pointed out above, password recovery is your friend here

Did anyone find a solution for this? Having same issue and it's kind of a bugger.. I find myself constantly dragging CKEditor windows larger

Try contacting those who made current version via related forum thread, http://processwire.com/talk/topic/926-french-fr-fr/. If they're no longer around, you could always release your own version anyway. Translations can be found from modules directory, see http://modules.processwire.com/categories/language-pack/. If there's an outdated version there, you'd have to either find the original author or ask Ryan for help with this. I'm afraid that this is really a question to Ryan, but as a partial answer: so far I can't remember hearing of any security issues with PW, so there's not much data to base this on, but I would expect all affected (and still available via GitHub etc.) versions to be fixed if one was actually found. If not by Ryan himself, then definitely by someone else around here. We're rebuilding some sites with PW that were originally built almost a decade ago.. so I would definitely answer "yes" here. In our case 4-5 year lifespan is very common and I honestly wouldn't have even considered PW if I thought that was a problem. Minor versions (as in 2.1, 2.2, 2.3) tend to be pretty big updates for PW, though I don't think any of them has really broken anything big time -- I've updated sites successfully from 2.1 => 2.2 => 2.3 without having to rewrite any code at all. Ryan has definitely made these updates pretty painless, trust me (just take a look at this thread, where version 2.4 compatibility with 3rd party modules was discussed.) On the other hand I would still recommend taking the approach of only updating sites between those if there's a need for it. It would be nice to always have all your client sites (especially if you're hosting those yourself, like we are) at the same (and latest) version, but honestly speaking that's not always meaningful. If there's something in the next minor version you really need, then by all means update. There have been proper update instructions for these jumps that you really should read first, though switching from 2.2 to 2.3 pretty much only meant replacing core files with new ones and so on. Updating from 2.0/2.1 to 2.2 was a bit more complex, I believe, as 2.2 introduced whole language support system - we probably won't get that kind of stuff all the time.. Keep in mind that PW is nothing like WP, where unattended site becomes a black hole of security issues in a few months. As I mentioned before, I haven't heard of a single, fatal security flaw so far and I've been around for a while. Oh but we do: http://processwire.com/talk/topic/1109-processwire-irc-channel/ No problem - and welcome to the forum!

Thanks Pete, already saw one "answered" -label today.. now we just need more solved cases ;-)

.. and in case that you actually want to alter values of previously created repeaters, not just create new ones, seems that this related thread holds an answer for you. You'll have to save the repeater items individually, not just page that contains them. Try something like this instead: $faqQA = $page->faqQA->get(0); $faqQA->of(false); $faqQA->title = '1'; $faqQA->body = '1'; $faqQA->save(); Completely untested and not something I've ever done, but looks like it should work (and kind of makes sense since repeaters are, under the hood, actually pages.) Edit: fixed broken example. Probably

@gtoirog: have you tried reading the docs, most importantly http://processwire.com/api/templates/ and http://processwire.com/api/variables/? This is all explained there

@NoDice: shouldn't be any specific problems with that - though it wouldn't hurt to do some kind of test-run for moving the site before actually publishing it. You know, just to make sure. Regarding link issues, check this thread too, there are couple of methods to fix and/or avoid these mentioned. In short, either do the page save trick introduced by Soma, dump SQL and search+replace as mentioned by Ryan or install Page Link Abstractor to avoid the whole issue entirely (read the module description carefully, though, as it changes the way your links work a bit.)

First of all: welcome to the forum, @NoDice! Not that much really, though it naturally depends on your past experience and so on. With CushyCMS (as far as I can tell from a quick look at their video guide) you'll have to learn how their system works, insert special attributes within your HTML markup and stuff like that. With PW you'll be learning how to insert basic PHP tags within your markup -- not that big a difference. Before you install PW and dive into it's default templates, I'd suggest that you read the basics of working with PW from our docs. ProcessWire is a very simple system to learn: all you really need to understand in order to get started are the basic concepts of pages, templates and fields (and a little bit about querying them and their values with the API.) As an example, you could have a template called basic-page with fields "title" and "body". By default that template would use basic-page.php in /site/templates/ as it's template file. To print out whatever values those fields have you could do this in said template file: <h1><?php echo $page->title; ?></h1> <p>This is static content, not coming from any page field. This will appear on <strong>each page using "basic-page" template</strong> as-is.</p> <?php echo $page->body; ?> Doesn't look too complicated, now does it? Of course you will pretty soon need a few other tricks, such as using foreach to iterate through things like image field containing multiple images, but that's all described in the docs and it's also dead simple. As @MarcC pointed out, it's possible but since multiple pages typically share one template you'd be affecting all of those pages. Then again, if you have a special page for something specific (such as "contact us") you can always create a new template (and a new template file) for that page.. OR you could do something like this in any of your template file: <?php if ($page->url == "/contact-us/") { ?> <h3>Our office is located here:</h3> <iframe width="425" height="350" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="https://maps.google.com/maps?q=disneyland,+paris&output=embed"></iframe> <?php } ?> With ProcessWire your options are almost limitless. Don't worry, it'll all fall in place once you start playing with it It's a bit ugly and not something I'd recommend, but: you can also have a field (or a couple of fields) in your templates (all of them or just some) that spit out raw HTML, CSS, JS etc. I say it's "ugly" because it could easily lead to various problems, such as broken page structure and so on, and I certainly would like to avoid such a thing on a client-managed website -- but as long as the site is managed only by you and a few other all of whom know enough to be careful not to break anything and not to insert any dangerous, external scripts etc. it's feasible option. Edit: just wanted to point out that essentially you're wondering whether to use an easy-to-use yet full-blown CMS with almost infinite possibilities (PW) or something that's designed to be "an easy way to change content" (CushyCMS.) Think about it this way: getting used to PW will take more than those "few minutes" CushyCMS promises, but once you do learn how to use it there's absolutely no limit to what you can do with it. On the other hand, if you're a) certain that your needs will stay small and b) really prefer a hosted, service-free tool then you should definitely go with CushyCMS. All in all it depends on your needs and preferences

Have file permissions by any chance changed -- ie. does whatever user your web server is running as have write access there etc.? That would probably be the most common reason for something like this. If you're not sure which user that would be and your site is running on Linux, "ps aux | grep apache" (or echo shell_exec("whoami") in any PHP file) will give you good idea. .. oh, and of course there's always the possibility that there simply haven't been any errors ..

There's something wrong with your MySQL credentials, doesn't seem to be related to PW itself. Make sure that you've typed them in correctly and if it still won't work, you should contact hostinger.ru support about this issue.

Go to Admin > Modules > find module called "Page Search". There's a setting for "Default fields to search".

@Pete: any chance that solved-button could be added to "New content" view also? Just noticed that it doesn't show up there -- which would be pretty sweet, considering that it's pretty much the only view some of us (well, at least me..) ever use

Textformatter for Google Maps https://github.com/teppokoivula/TextformatterGoogleMaps This module looks for Google Maps URLs (such as https://maps.google.fi/maps?safe=off&ie=UTF-8&q=disneyland,+paris) within paragraph (<p></p>) HTML tags and automatically converts them to embedded maps. Configurable options include embed type ("static" or "iframe"), API key, responsive embedding and Google Maps for Business settings. Other than that, it's pretty basic stuff. Original regexp for grabbing maps links was posted by Ryan (I believe) here on the forums, but I couldn't find that post anymore. I've altered it to better suit the needs of this module, added some configurable features (part of which, such as makeResponsive() method, are again based on Ryan's TextformatterVideoEmbed module) and so on. Hope someone finds it useful. (By the way: if you're going to use Google Maps for Business settings, please read the notes there carefully. Google doesn't exactly recommend storing your private key the way module settings are stored..)

I'm sure you already know this, but still: Location can't be reliably identified based on IP alone. Even if you use a very large list of IP's connected to location data that some sites distribute, you'd still have to take into account various proxy services, possible human error etc. Essentially this kind of feature is OK for offering extra value for some users, but it's definitely not a good idea to rely on it alone to provide any security-related features. Just saying. But to get to your questions.. If you're going to have a lot of IP ranges (and you'll probably have if your list is even half comprehensive) this might be a very good idea. As a matter of fact, since you mentioned it here, I've started thinking that perhaps I should include something similar to the original module itself.. can't give an ETA for that yet though, and it might not even be of benefit in your case This is a tricky question. First of all, I'd suggest looking into Markup Cache -- it'll allow you to cache parts of your page, even if whole pages can't be easily cached. That's probably the easiest method here. Other option would be caching two versions, like you've pointed above, but as far as I know that's not really an option available out-of-the-box. Template Cache allows you to cache URL segments, so you might be able to work around this problem using that for an example. Could get very complicated very fast though. With commercial Pro Cache module you can bypass the cache when certain cookie is set.. though it might be difficult to set that cookie if pages keep getting served from cache. That could be an option if you're relying on some pages not being cached, ie. users always entering via root page which won't be cached at all. Doesn't sound like a good idea, but I don't really know your whole setup, requirements and plan here either, just throwing in ideas Edit: as a matter of fact, you could probably also use modified Page Render IP Restriction to set $session->PageRenderNoCache and that way skip Template Cache for either local or non-local users, even without relying on Pro Cache module. Page Render IP Restriction runs before Template Cache can work it's magic, so this should be possible. Obvious downside here would be that part of your audience won't benefit from caching at all.

Not sure what you mean with these .json and .zip files, but I'm guessing you're saying that they weren't there in some language pack you've downloaded? Not all language packs contain all files -- there may be more translatable phrases now than there were when the language pack was created etc. so you'll have to either translate these manually or post a heads-up about these to the maintainer of that particular language pack. Anyway, if you want to translate this file manually then just follow these steps: Log in, go to Setup > Languages and select target language At the bottom of "Language translation files" follow the "translate new file" link Type whole path (\wire\modules\Inputfield\InputfieldPage\InputfieldPage.module) in the "File to translate" input Translation page should open -- now you'll just have to translate phrases manually and save If I'm understanding something wrong here, please provide some extra information about what you're exactly trying to do.