ryan

Adrian, sorry for some reason I got it stuck in my head that we were talking about API level adding of images rather than capturing those added from the admin. The install() method doesn't get called on images added from the admin because InputfieldFile puts them right in the target directory, if I recall correctly. So I think the hook that you would actually want would be one of these methods (both of which are already hookable): InputfieldFile::processInputAddFile($filename) This one adds the given $filename to the $pagefiles, perhaps you could rename $filename it on a before call and change the value of $arguments[0] to be your new filename? or... InputfieldFile::fileAdded(Pagefile $pagefile) This one is called after a new file is added, giving you the completed $pagefile

Which version of ProcessWire? It sounds like you are using multi-language support, in which case I'd strongly suggest using the dev branch (2.3.5).

Those are two different selectors. The first is looking for pages with the phrase "guitar lessons" in title or body. The second is looking for pages with the words "guitar" OR "body" in the title or body. If the first one is failing, then that would be because the phrase "guitar lessons" don't appear in the body of any pages exactly like that (though this is not case sensitive). This sort of thing can be affected by spacing too, so if you see "guitar lessons" on a page, view the source and see if there are actually two spaces between the words or perhaps a pesky or something. You might also want to consider if "title|body~=guitar lessons" might be better for your needs here. That would match pages having both of the words in either the title or body, but they wouldn't have to be phrased together.

Just added and will commit this weekend–thanks Soma.

It's using URL segments, where the number (id) is the URL segment. Here's the code from that template if it helps: <?php $id = (int) $input->urlSegment1; if($id < 1) throw new Wire404Exception(); $marker = $pages->get("template=map-item, id=$id"); if(!$marker->id) throw new Wire404Exception(); echo $marker->render(); That $marker Page is a page using template map-item. The map-item template contains the fields for each map marker item like location/coordinates, categories and notes. The implementation of the template file is just to output a <div> with that info in it, and that's what gets sent through that $marker->render() call above, which goes straight through ajax. It's not technically necessary to do it this way, but it does enable us to just pass through an ID on the front-end, since the full URLs take up more space without offering any real benefit in this case. So it's just more efficient to route through a known, consistent URL with an ID appended to it.

You can also just check the page type within the hook function. By simply issuing a 'return' if it doesn't match the template you want, that duplicates the behavior of accessing an unknown property (resulting in a null value being returned to the caller). wire()->addHookProperty('Page::hello', function($event)) { if($event->object->template != 'basic-page') return; $event->return = 'hi'; });

Thanks Soma, I will add this too. I'm not totally sure I understand how it works, but have pasted it in here and will follow in more detail.

I think it's because we're using a substr() there rather than an mb_substr(). You could try applying this change in /site/templates/blog.inc as I'm thinking that might fix it? (essentially replace "substr" with "mb_substr" and "strrpos" with "mb_strrpos"): diff --git a/templates/blog.inc b/templates/blog.inc index b68abd5..e1096c2 100644 --- a/templates/blog.inc +++ b/templates/blog.inc @@ -118,8 +118,8 @@ function renderPosts($posts, $small = false) { if(empty($page->summary)) { // summary is blank so we auto-generate a summary from the body - $summary = strip_tags(substr($page->body, 0, 450)); - $page->summary = substr($summary, 0, strrpos($summary, ' ')); + $summary = strip_tags(mb_substr($page->body, 0, 450)); + $page->summary = mb_substr($summary, 0, mb_strrpos($summary, ' ')); } // set a couple new fields that our output will use Please let me know the result.

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