ryan

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

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?