ryan

I'm actually adding this to the ProcessPageEditImageSelect module configuration just to avoid having to update two modules for this, as well as to minimize the configuration options in the Setup > Fields > field screen, as I'm guessing this option isn't needed by most. I've already put it in place, so will test here and then commit soon.

Not sure about, as it doesn't really sound like the same thing. Have you tried updating your version like mangopo mentioned? You may want to try using the dev branch. But regardless of whether you go for 2.3.0 stable or 2.3.5 dev, make sure you replace the /wire/ directory entirely, and not replace into it .

Okay that makes sense. We entity encode everything coming from the translation functions for security. I believe that htmlspecialchars/htmlentities have a boolean argument that when 'true' can tell it to not double-encode. But for a quick solution in your case, you could update that line in your module to this (below), and I'll update the ProcessModule to have that boolean argument. 'summary' => html_entity_decode(__('Here comes the text')),

Not sure I fully understand the scenario. But it sounds like you've got a dialog box popping up before you want it, or a redirect occurring before you want it. You could delay the dialog by using javascript setTimeout() to load it. As for the redirect, you could always resort to a javascript-based redirect: window.location.href = 'target url'; to occur any time during or after page load (again setTimeout() might come in handy here).

It doesn't matter if it's a new file or not. What matters is whether it's already located in the destination directory. If it's already in there, then the install() method won't be called and hooks to it wouldn't be called. That's because the purpose of the install method is to copy a file from one location to the destination. I mention this because it's not uncommon when doing data conversion jobs to put the file right in the destination directory before adding it to ProcessWire's data. But since you want the install() hook to be called, you'd want to ensure that the files you are adding aren't already in /site/assets/files/... Let me know if I'm wrong about my guess about the file already being in the destination? If so, please post the code you are using for the non-working hook and I'll experiment here. Your module and screenshot look awesome, btw.

In this tutorial we make a simple function that becomes part of every PageArray. Once hooked to the PageArray class, you can call this function from anything returned from $pages->find(), $page->children(), or your own page references like $page->categories from the blog profile, etc. It essentially becomes a new function available to you from any PageArray anywhere in your site. First, lets look at what convenience the hook function adds and how we might use it. We'll call the hook function "renderLinks", but you could of course call it whatever you wanted. We call that renderLinks() function from any PageArray, and it returns a string representing that PageArray as a list of links. By default, this renderLinks() functions separates each page with a comma, and outputs the page's title as the anchor text. We can change that to be anything by specifying arguments to the call. The first argument is the delimiter, which defaults to a comma ", " if not specified. The second argument is the name of the field to output, which defaults to "title" if not specified. Next are 3 examples of how this renderLinks hook function could be used. Usage Examples: Example 1: render a comma-separated list of links: echo $pages->find("parent=/")->renderLinks(); Output: <a href='/about/'>About Us</a>, <a href='/contact/'>Contact Us</a>, <a href='/site-map/'>Site Map</a> Example 2: render a <ul> of $categories links: <ul> <li> <?php echo $page->categories->renderLinks('</li><li>', 'title'); ?> </li> </ul> Output: <ul> <li><a href='/categories/category1/'>Category 1</a></li> <li><a href='/categories/category2/'>Category 2</a></li> <li><a href='/categories/category3/'>Category 3</a></li> </ul> Example 3: render a breadcrumb trail: <p class='breadcrumbs'> <?= $page->parents->renderLinks(' / ') ?> </p> Output: <p class='breadcrumbs'> <a href='/parent1/'>Parent 1</a> / <a href='/parent1/parent2/'>Parent 2</a> / <a href='/parent1/parent2/parent3/'>Parent 3</a> </p> Those examples above show some of the potential of how you might use such a function. Next is the hook function itself. In order to be available to all templates in your site, it needs to be defined somewhere consistent that is always loaded... Where to put the hook function: If using the basic profile (that comes with ProcessWire) you could put the hook function at the top of your /site/templates/head.inc file. If using the Foundation or Skyscrapers profile, you could put the hook function in your /site/templates/_init.php file. This is the method that I use. If using something else, you could create a /site/templates/_init.php file with your hook function(s) in it, and then edit your /site/config.php to point to it with the $config->prependTemplateFile = '_init.php'; so that it is automatically loaded on every request. Note that the name "_init.php" is not required, you can name it whatever you want. You could put it in an autoload module... but that might be overkill here. The actual hook function: wire()->addHook("PageArray::renderLinks", function(HookEvent $event) { // first argument is the delimiter - what separates each link (default=comma) $delimiter = $event->arguments(0); if(empty($delimiter)) $delimiter = ", "; // second argument is the property to render from each $page (default=title) $property = $event->arguments(1); if(empty($property)) $property = "title"; // $out contains the output this function returns $out = ''; // loop through each item in the PageArray and render the links foreach($event->object as $page) { $value = $page->get($property); if(!strlen($value)) continue; // skip empty values if(strlen($out)) $out .= $delimiter; if($page->viewable()) { // if page is viewable, make it a link $out .= "<a href='$page->url'>$value</a>"; } else { // if page is not viewable, just display the value $out .= $value; } } // populate the return value $event->return = $out; }); If using PHP before 5.3, or using an older version of ProcessWire, you'll need to change the first line to this (below). This syntax also works with newer versions as well, but it's not as pretty as the new syntax. wire()->addHook("PageArray::renderLinks", null, 'hookRenderLinks'); function hookRenderLinks(HookEvent $event) {

I've noticed that the TinyMCE language files are all just the first part of the language code, i.e. "zh" rather than "zh_CN". I think that the full code is what TinyMCE 4 is using, but it doesn't look like 3.5.8 does. Have you tried renaming it to just zh.js? Also, the page you linked to is the TinyMCE 4 language pack directory, and I don't think those would be compatible with TinyMCE 3.5.8, though not positive on that.

If it's just one page that you have that situation on, then you can check for the page in the _main.php file and bypass the usual output, i.e. _main.php <div id='content' class='row'> <? if($page->id == 1): // homepage ?> <div class='large-12 columns'> <?=$body?> </div> <? else: // regular 2-column output ?> <div class='large-8 columns'> <?=$body?> </div> <div class='large-4 columns'> <?=$side?> </div> <? endif; ?> </div><!--/#content--> For cases where I want the option of specifying something entirely different for <div id='content'> from any template, I'll setup the option to specify a $content variable. From the _init.php you set it to be blank (the default value): _init.php $body = $page->body; $side = ''; $content = ''; // add this Then in your _main.php, you check for the presence of it. When present, the usual body/sidebar layout is bypassed and you get to specify something entirely different, simply by populating the $content variable, rather than $body or $side. _main.php <? if($content): // custom $content ?> <?=$content?> <? else: // regular 2-column output ?> <div id='content' class='row'> <div class='large-8 columns'> <?=$body?> </div> <div class='large-4 columns'> <?=$side?> </div> </div><!--/#content--> <? endif; ?> From that point forward, your templates can choose to populate $body and $side, or if the layout needs are different, then populate $content instead. Here's an example of what a hero + 3 boxes below homepage template might look like: home.php $content = " <div id='content' class='row'> <div class='large-12 columns'> <img src='...' /><!-- giant hero image --> </div> </div><!--/#content--> <div id='features' class='row'> <div class='large-3 columns'> <p>Feature box 1</p> </div> <div class='large-3 columns'> <p>Feature box 2</p> </div> <div class='large-3 columns'> <p>Feature box 3</p> </div> </div><!--/#features--> ";

I'm really curious to know where that tools.php is coming from. If you edit your /http404/ page, what template is it using? Is your site based on an existing profile?

I agree, but think the "you are a true hero" probably qualifies as a like, or likely something better. I think there is a concern among new users that clicking "like" will send them off to Facebook and post something on their wall. Thankfully it's just a regular like button like those we had before facebook, and has nothing to do with facebook.

Nested repeaters aren't supported because it introduces a high probability of issues. As a result, there isn't a config option to enable it. The repeater code just isn't designed to nest like that. Usually envisioning your structure as a page tree is the best solution for something like this. But if that doesn't work, or you don't want to do it, another route is to make "section" a page reference (select field) within a menu-item repeater. Every repeater item would have a 'section' select where they choose what section the item goes in. Alternatively, the sections could themselves be pages, each with a menu-item repeater. Even if you could nest here, I actually think it simplifies your site a lot to use the page structure rather than repeaters in cases like this, because it adds more clarity to working with the items from the development side. And it is something that is ultimately more scalable (though not sure if that matters in this particular instance).

It might make sense for Hanna code's parser to just allow " as an allowed attribute container, in the same way it does unencoded quotes? I'm happy to implement this change if you guys think it would solve the issue without creating other problems (I can't think of any at the moment).

It sounds like Windows/IIS isn't honoring your upload_tmp_dir PHP setting, or it isn't being set. Just to double check: in your /site/config.php file, that setting is commented out by default. Meaning it's between /* and */ characters. Make sure that it is uncommented, so that the setting takes effect. It should look like this: /** * uploadTmpDir: optionally override PHP's upload_tmp_dir with your own * */ $config->uploadTmpDir = dirname(__FILE__) . '/assets/uploads/'; // example not this: /** * uploadTmpDir: optionally override PHP's upload_tmp_dir with your own * * $config->uploadTmpDir = dirname(__FILE__) . '/assets/uploads/'; // example * */ If that doesn't work, try changing those slashes to Windows-style back-slashes, just in case (not sure it matters here, and I'm not next to the code to double check). Next thing is to make sure that the directory is writable by your web server.

ProcessWire's session setup is pretty much 100% consistent with PHP's recommended setup for them. I'm guessing that change the host made would affect most CMSs. But they probably only care if it affects WordPress. I agree with Apeisa that switching to the database sessions might have fixed it in this case, as it's specifying a custom session handler rather than letting PHP go it's usual session route. But it sounds like this host's change may have broken it to the point where you couldn't even enable that module from the server. It might require moving site site to a local/dev server, installing the module, then moving it back. A pain for sure. If this site is still down, let me know and I'll see if I can come up with anything simpler to do the switch for you.

Nice work Soma. I haven't yet tested, but have looked through the code and it seems solid to me. I don't yet have any instances where I'm using multi-site in production, but need to start doing so–very useful. Even more so extended like this.

Joe, I tested here and all seemed to be working how it should. Then I noticed I had some uncommitted updates pending in my JqueryCollagePlus dir. I went ahead and committed them to a new version. Please give the latest a try and let me know if that fixes it for you?

Sir Trevor definitely looks interesting and a great idea. It seems like this could solve a lot of the bad-markup-from-RTEs issue. Though I'm not yet convinced this is better than an RTE for most. At least in testing it out here I found it to be more of a hassle inputting content... though maybe it's just something to get used to. I'm also looking for how to input headlines and not seeing the option to do so--I'm assuming they'd do that with one of the "+" plugins. But it does call into question how clients would go about pasting content in a convenient manner (probably the most common input methods clients use). But this does seem like a good project to keep an eye on.

Not currently, but if there's enough demand for it perhaps we could add a checkbox to the FieldtypeImage field settings that amounts to the effect of "prevent this field from being used in textarea fields".

You may need to test to find out for sure. But if you find it's not exhibiting the behavior you need, I should be able to track down the line you'd need to change and suggest what to do.

Recent versions of the dev branch add some more classes in there (if I'm remembering correctly) to make more style options possible in the pagelist. The separator character is now added by CSS rather than being in the markup, which is probably why it started showing up there. If it turns out to be problematic, I can change it back to a non-css solution for that.

Most likely you are competing with a hook running from LanguageSupportPageNames. I'm guessing your hook is running and doing something, and the hook in LanguageSupportPageNames is undoing what you did. Since LanguageSupportPageNames is using "saveReady" rather than "save", by you switching to "save" I think that's why your results are more predictable. If you really needed to use saveReady, you may also be able to resolve the issue by setting a hook priority value or attaching your hook at a later point than LanguageSupportPageNames does (perhaps in a ready() rather than an init, or a render() rather than a ready(), etc.). But if the "save"hook accomplishes what you need, I'd stick with that solution.

The problem here is that you are outputting the same exact thumbnail 4 times. I'm guessing maybe something like this is what you wanted? <div id="portfolio_list"> <ul class='bxslider'> <?php $features = $pages->find("template=project, sort=-date"); foreach($features as $feature) { $thumb = $feature->thumbnail ? $feature->thumbnail->width(800)->url : "http://i.imgur.com/1zxfxMW.jpg"; echo "<li><img src='$thumb' /></li>"; } ?> </ul><div> Either that, or if you were wanting to output 4 images from each $feature page, then you'd want another foreach within that loop that iterates over the images in $feature.

Also make sure that you have writable and existing /site/assets/cache/ and /site/assets/sessions/ directories.

What address are you trying to geocode? I want to try it here just to see if there's something unique about it that might be confusing Google's geocoder. Also, when the JS geocoder runs, it should bypass the server side geocoder unless something changes about the address during the save. If that's not the behavior you are getting, let me know what browser and version you are using \.

While I agree that the ID appended fields may not be perfect, they turned out to be the best option after considering many others within the context of the entire system. The direction was chosen very carefully, and I have worked on multi-language databases setup exactly as you described for mass data conversions. There are a lot of considerations that go into the structure that was decided upon from selector engine findability to compatibility, ease of conversion from/to multi-language, eliminating potential overhead for non-multilanguage environments, support for different types of multi-language environments, overall efficiency/speed and much more. The longer term plan is to outsource the ID to a separate table and use predictable names for the current ID appended versions, but that's just a minor change as a matter of portability and not going to matter to most. I also want to mention that we already support any field being multi-language via Language Alternate fields, which may sometimes suit your purpose better than multi-language fields, even for regular text fields. Nothing about using the LanguageSupportPageNames module (which adds the new name columns as needed) interferes with name being required to be unique within the parent. That aspect remains regardless of whether using multi-language page names or not. However, it is possible for more than two languages to have the same name for the same page, and this is intended. Some languages use the same terminology and words, so it would actually be a limitation if we enforced uniqueness across them. It also enables use to fall-back to the default language for instances where someone wants to use multi-language page names in some instances and not others. In a multi language environment, the language is determined from the overall path, not the individual page name. This is an important aspect of multi-language page names, as there is often a lot of crossover in terminology between different languages. This is one reason why we recommend (though don't require) that you at least set a starting segment for the language on your homepage, i.e. /de/, /en/, /es/, etc.