ryan

I've got no experience with IIS so not sure how to troubleshoot with it. (PW doesn't technically support IIS, though some are apparently using it without trouble). Maybe someone who is using PW with IIS could suggest things to try.

Dragan, have a look in your image/file field settings (Setup > Fields > your-file-field) on the "input" tab. There is a option there asking how many row you want available for the description.

Thanks for your work here liyiwu! If you get a chance, can you add to the modules directory here? http://modules.processwire.com/add/

If anyone knows of a good permanent solution for this issue that doesn't break in one language or another, please let me know or submit PR or patch. It seems like PHP has setup numerous tripwires on this one for us. Until we get this one figured out, I think Kixe's solution is probably the best way to go if you need to reliably store floats across languages that use different things for decimals. But I'd like to get a permanent solution in place for FieldtypeFloat, as text is not the ideal way to store these numbers from the DB, or make them searchable. But at least it's reliable.

Tested this one out, but seems like it might be very out of date? It apparently doesn't recognize HTML5, and is suggesting use of XHTML MP while quoting mobile compatibility from a year range of 1999-2007. There seemed to be a lot more false positive stuff, but I stopped looking after that. 2007 is pre-iPhone and Android and things have changed a lot.

Rest assured this will be added soon (along with Horst's updated ImageSizer stuff), and certainly before the version is bumped to 2.4. Thanks Soma for your updates here. There are a lot of people using dev in production, and there were just enough code changes/additions in this one that made me want to be sure I took the time go go through it thoroughly line-byline in the code, and then test thoroughly. It often takes me a couple hours to work through individual pull requests to feel like I've given them all the attention they deserve. So while I'm not good at being timely with it, I am generally good at being thorough with it. Also, as Soma mentioned, busy times (looming client project deadlines, which always seem to gravitate towards the final months of the year). But thankfully those busy times are just temporary, as ProcessWire is where I prefer to spend my time.

Thanks for the tutorial webweaver. Any idea why it's necessary to turn off ACF? The only reason I could think of is if the justify plugin isn't registering its markup/attributes with CKEditor, but that would be unusual given that it's included with CKEditor. I think ACF is a good thing and I avoid disabling it if at all possible.

If it's working now, I think you should be fine to have that line commented.

The language translation tools are intended to be admin-only, so assigning permissions for that isn't supported by default. There are potential security implications with making it a default/supported capability. But it is something you could add relatively easily by editing the ProcessLanguage.module and ProcessLanguageTranslator.module files located in /wire/modules/LanguageSupport/. In the getModuleInfo() function of each, you'd want to add a 'permission' line, like this: static public function getModuleInfo() { return array( 'title' => __('Languages', __FILE__), 'version' => 100, 'summary' => __('Manage system languages', __FILE__), 'author' => 'Ryan Cramer', 'requires' => 'LanguageSupport', 'permission' => 'language-edit' // ADD THIS LINE ); } Then in your admin, go to Access > Permissions and add a new permission called "language-edit". Give that permission to any roles you want to be able to use these tools.

I'm not sure about it from the ImagesManager side, as I don't have as much experience with that module. But what you are suggesting seems fine. Generally you can take the pages concept to apply towards management of any kind of data, including files/images, and it tends to work pretty well. With regard to "tags", that implies using the existing tags built-in to files/images or using text fields. You may find it more worthwhile in this case to use page references for your artists, authors, venues, etc. while associating each image with a page, and select the related artists, authors, venues with each one of them.

Strangely I've not ever run into this issue, and I guess it just depends on whether the editor is entity encoding quotes or not (it looks like CKEditor does not entity encode quotes, so no problems with Hanna code). I've gone ahead and added support for " entity encoded quotes to the latest version.

I agree that article is pretty uninformed and it's that kind of rationale that is holding back the web on a large scale. It's why most of the web is powered by decade(s) old technology and thinking. I'm not sure why about.com would write such an article without any experience with the systems. I am guessing the author's experience is limited to WordPress, but he bundled Drupal into there because he heard it's big, and the other side of the coin to WordPress (for balance). I actually think the article would have been more valid if Drupal had been left out and it was clear that the audience was intended to be those with no web experience. It seems like some of the intended audience becomes more clear in the author's follow-up comments. I have actually developed sites in both WordPress and Drupal - I can think of a lot of folks I would recommend WordPress to (it's hard to beat for a simple blog), but really can't think of anyone I'd recommend Drupal to in this day and age. I like and respect a lot about Drupal actually, but it's for nostalgic reasons not practical ones. It's like tinkering around with my old mechanical calculator form the 1960s. It can still get the job done, but it's hard to rationalize using it given what else is available. The one thing I did like about this article was the follow-up comments by Diogo and Joss, that's where the real quality content is here. And it made my day to see Joss pop up in there, assuming it's the same one from here.

Debug mode means that PHP is reporting specific error messages. It's something you want when developing a site, but not once a site is on a production server. The debug information that you see in the admin is primarily for development of ProcessWire and modules. It would be possible for you to output something like that on the front-end too, but since ProcessWire isn't generating the markup for your site, it's up to you to decide what/how you want to handle additional output in debug mode. That's a good idea by Adrian to just include the admin version of it, if it suits your need... I'm guessing it's not pretty unless you are using jQuery UI on your front-end, but if it works, it seems fine to do it.

I've updated this module to support the new admin theme. It just required a few changes to the VersionControlForTextFields.js file (I had to rename it to .txt because the forum won't accept a .js attachment). It should support both new and old admin theme. But I'm posting here rather than doing a pull request because I haven't had time to adequately test it beyond my own environments where I'm using it. Teppo: I've also attached a patch/diff. rc-patch.txt VersionControlForTextFields.js.txt

@lpa: LanguageSupportPageNames works by hooking several things, including items involved in rendering pages. In your case, you are bootstrapping ProcessWire yourself and so none of the ProcessPageView / PageRender hooks would be executed. I'm wondering if that might be the problem here. While I still think what you are doing should work (ideally) I'm wondering if moving your code to a template file, and then viewing a page using that template makes any difference?

It sounds like the connection is being blocked server side via a firewall or perhaps limitations imposed on PHP's functions for security. Go ahead and grab the latest update FieldtypeMapMarker/InputfieldMapMarker 2.0.5 which should bypass the need for server-side geocoding in many cases, including yours I think.

Have a look in the /wire/core/FileLog.php file -- it contains a prune($bytes) method that you can use to reduce the size of the file. In your case, you may want to have a LazyCron hook prune the file to 100000 bytes or something near there. You could also just prune the file before or after your $log->save(). $log = new FileLog(wire('config')->paths->logs . 'mylog.txt'); $log->prune(100000);

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--> ";