ryan

Good to see you here Joss!! If Teppo keeps this up, we'll just have to add a new docs tab on processwire.com that goes straight to his site.

It sounds like there are various issues turning up as a result of this box sizing, though the only one that strikes me as a big concern is the image stretching Soma is seeing. What do you guys recommend as a fix for this? I originally added the box sizing per the recommendations here. Happy to change anything that needs changing, but not clear on what to change. Feasibly we could switch to a different icon set in the future, and the icon-iconname format strikes me as more portable? The fa-iconname format seems to be branded specific to Font Awesome. It looks like you've got a new /site/templates-admin/ without a corresponding new /wire/ directory. Click on the "download ZIP" button on this page. Take the /wire/ directory and replace with your existing /wire/ directory. Then take the /site-default/templates-admin/ directory and replace your /site/templates-admin/ directory with it. Can anyone with a PC and chrome confirm that the fonts are displaying correctly now that we've switched to self-hosted Arimo? It sounds like the easiest way to tell is whether the letter "e" looks like the screenshot in the post above this. Does anyone have any ideas on how to fix the submit buttons that aren't registering half the time?

Just committed, so it should be there now on dev. Modules > Core > Process > Image Select

Are you wanting to store just the selector (text) or both the selector (text) and the resulting page IDs? I'm thinking just the selector text, since the resulting pages may change ... that's what's kind of unique about storing the selector string, as the results of it really couldn't be known until runtime. If that's the case, then I don't think there would be any reason to extend FieldtypePage, as it is heavily geared towards storing IDs of page (references). Your own Fieldtype could store just the selector string, but expand that to a PageArray in the Fieldtype::formatValue function, as one possibility. The main disadvantage of storing just the selector is that you couldn't query the field from another selector to know what pages were stored in it... since the results are determined at runtime and not stored on disk. If you only need the selector string as a way to determine which pages are selectable (as opposed to which pages are selected), then this is pretty much in-line with what the PageAutocomplete inputfield does. Only it sounds like you need to define this selector on a per-page basis, rather than a per-field basis. Your Inputfield certainly could create its own DB table if you wanted it to. While it's true that dealing with the storage-side is exclusive to Fieldtypes, this one would be kind of a grey area. If it suits your needs and is ultimately simpler, don't be afraid to have your Inputfield create it's own DB table and store whatever it needs to. But keep in mind that by taking this route, it may prevent the Inputfield from having much value in other contexts like other Inputfield forms or FormBuilder (which may not matter) ... this is already the case with PageAutocomplete and PageListSelect Inputfields.

This is specific to the PW blog profile -- after adding the new template for the widget, you'd go to Pages > Tools > Widgets > new. Add a new page in there called Google Plus, using the new template you just added.

I can't duplicate that here. Are you sure you've got the latest version? Do you have the checkbox checked that is between address and latitude? Try hitting reload once or twice on the page as well, just in case something older is cached.

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.