adrian

Just to close out the issue that @adrianromega had - turns out it was simply due to diacritics. Once the characters were added to the replacements section of the InputfieldPageName module settings, everything worked as expected.

I think the message behind the new wording is that the you should stick with the stable version for existing sites because in some cases behaviors may have changed with the dev version and there might potentially be issues with 3rd party modules. The reason it is ok to use dev for new sites is that you are checking that everything is working as you are developing the site so you know that everything is working as expected. Personally I use dev on all my sites, but wait a little while to upgrade when Ryan has noted that there are some major changes - also I test these new changes for a bit on my dev sites so I understand the changes and help to debug any issues that may have arisen. Out of interest, check out the results of the poll on what versions people are using where: https://processwire.com/talk/topic/8946-dev-or-stable-branch/

I completely agree, except it should be PageTableExtendedInline - to me that would be a great interface - need to think about how complicated this might be to put together I also don't like the modal approach of PageTable - that is definitely where repeaters have the edge - that said, repeaters have too many limitations so I don't ever use them.

Interesting - chosen actually works on tablet sized devices, but is disabled on phone sized ones. The issue I mentioned above doesn't seem to be an issue on Safari on tablets. Having this not work on phone sized devices though is quite a problem - the selection of existing pages works well enough, but not being able to add new ones is a deal breaker for me. I haven't tried it yet, but there is this fork of chosen that claims to work with mobile devices: https://github.com/rafalenden/chosen Maybe your module could fallback to ASM select with a textarea (for creating new pages) if on phone sized? Or maybe some other option - there has to be a cleaner way Not sure the best option yet - will think about it more later.

Just a quick note - there seems to be a bit of an issue on touch screens. Not sure if it is something related to your module, or the chosen library itself, but the first time I tap on the field, it automatically selects and adds the first page to the list of selected items. After that I can tap again and no selections are made. This happened to me on Chrome on iOS, but I haven't tested other browsers/devices.

haha Well to be honest, that hack of hani's module was about as easy as it gets - literally just a find/replace of "template" with "field" and it works I am actually wondering if FieldtypeModules, FieldtypeTemplates, and now FieldtypeFields should become one module so that we can have one codebase to maintain, but the dev can choose whether modules, templates, or fields are what is available for selection. Of course this option would have to be from the field settings, and not the module config settings so it could be on a field by field basis. Do any users of FieldtypeModules or FieldtypeTemplates have any thoughts on this?

This isn't possible with a page field, but I have quickly modified hani's Template ASM Select to create a Field ASM Select fieldtype. Let me know if this works for you as expected - maybe it should be released properly in case others might find it useful. FieldtypeFields.module

Such a clean illustration like that should be displayed as an SVG Seriously though if you don't need to support <IE9 you could have your editors upload as an SVG and it should work great. If you do need to support <IE8 or you have other illustrations which are more complex and you want to rasterize on the fly at the required size, you could check out: http://modules.processwire.com/modules/image-rasterizer/ although keep in mind that it does have some server dependancies that might not be available. @horst - what is the status of https://github.com/horst-n/PageimageSizerImagick ?

Hi @adrianromega - I have just set up a lightning.pw site running 2.5.3 and everything is working fine at my end. I am just about to PM you the login details. Could you please test at your end and let me know if it works for you. If it does work, then I think there might be another module causing conflict, although that seems unlikely unless you have some something that also has some JS affecting the live name creation process. If it doesn't work, then I am guessing a browser issue - what are you running? Are you getting any JS errors in your console?

Well unless you have previously defined $cursus to a value you should end up getting this error: Notice: Undefined variable: cursus Although even with that error, it does seem to work ok. I agree with @junofornow - that syntax is much cleaner, although I would use: $session->remove('cursus'); Sorry, I am not sure why you are having issues with Chrome - I might be completely off base here, but are either of these any help? http://stackoverflow.com/questions/8247842/session-data-lost-in-chrome-only http://stackoverflow.com/questions/2953536/randomly-losing-session-variables-only-in-google-chrome-url-rewriting

Well if you use the Page Auto Name module and put "id" in the Pattern field, you'll see that it successfully renames the page to the ID of page, so you could use that, or you could make use of the same hook they use, which is: before Page::save - https://github.com/conclurer/PageAutoName/blob/master/PageAutoName.module#L114 but you could also use saveReady, like mr-fan describes above. Page creation in PW is normally a two step process - first create the title and save - this automatically generates the name and id, and then you add other field content, and/or simply publish or save as unpublished. You need that initial save to have the id generated.

Do you really use: $session->set($cursus, $page->title); rather than: $session->set('cursus', $page->title); or was that a typo in the post?

Thanks soma, and sorry mr-fan! I hadn't thought things through fully - obviously Some more reading on it, in case anyone is interested: https://processwire.com/talk/topic/1705-need-to-send-email-notification-after-a-page-has-been-published/

Have a read over here: https://processwire.com/talk/topic/5286-switching-fields-to-language-fields-produces-fatal-errors/ I also noted a temp fix for you on the Github issue you posted.

EDIT - ignore this and see posts below I love direct sql as much as the next guy, but: $result = wire('db')->query("SELECT status FROM pages WHERE id={$page->id}"); list($status) = $result->fetch_row(); if($status & Page::statusUnpublished) { can be replaced by: if($page->status & Page::statusUnpublished) { You might also find this useful: $page->isNew();

This has been discussed a bit already: https://processwire.com/talk/topic/6771-max-size-textarea-field/ Not really sure why that limit as added to the sanitizer - perhaps file a github issue for Ryan to see if he might remove it, or make it configurable up to the 65,535 bytes that a MySQL text field can handle.

There is this module: http://modules.processwire.com/modules/page-auto-name/ that lets you define patterns for each template (or sitewide) for automatic page renaming. Another option you might be interested in is: http://modules.processwire.com/modules/process-redirect-ids/ which allows you to access pages by their ID (no matter what else is in the URL), even though they haven't been renamed.

Yes, they are equivalent, but you had: $wire->$input->post->search; instead of: $wire->input->post->search; Note the $ before input in your version. Sorry I should have explained a little more completely

$temp_var = wire('input')->post->search;

I just committed a small but significant change in behavior - now if you don't select any templates or pages in the config settings, the Batch Child Editor tools will be available for all pages in your site. I have found I want access to this a lot (mostly the rename, sort, and delete functionality of the EDIT mode) and it was annoying to have to go and enable it for the template or page before I could use it, so now it can easily be available to all pages on your site. Hope everyone else finds this more convenient also.

Just a guess, but what about the path to your query.php. You say it's in your website root, but if it's being called from a PW page, then you need to use a root relative path, likely just: url: "/query.php", Don't forget that you can find out if there was a 404 on that file in the Network tab of your dev tools console.

There are lots of options, but the two I like are: Using the template conditional options in AIOM: http://modules.processwire.com/modules/all-in-one-minify/#conditional-loading Or otherwise you can add the js script call in a variable in your template, eg: $end_head = '<script src="myscripts.js"></script>'; Then in your main.inc or whatever file is your master template, just echo out $end_head before the closing </head>. Of course you could also do this with $end_body if more appropriate for your script file.

PR has been submitted to fix those fatal errors in PHP 5.3. The other relatively minor (but niggly) thing is that the description field is not getting the InputfieldMaxWidth class applied to it and as a result, the input is very narrow. I took a quick look at the regex stuff you have going on in regard to this, but figured it was easier for you to figure out the issue with this because I haven't really figured out why you are replacing the label class and label for description, although I am sure there is good reason

Hi Ryan! Sorry for pestering, but now that 2.5.20 is out, I wanted to reiterate my concern around the min size issue - this really is a deal breaker at the moment. For example, if you plan to display a headshot of someone at 150px x 150px and you set the Min Image Dimensions accordingly, but then they crop or resize it using the new functionality, you will end up with a very pixilated image, or one that is too small (if upscaling is disabled) if your template call is $image->size(150,150)->url and they have made it significantly smaller. I also agree that renobird's idea would be a useful additional option, but based on your comments about the core functionality vs CroppableImage, I think you might think that is something beyond the scope of the core? The other critical thing in my mind is the ability to disable "Save as Copy" on a field by field basis - in addition to my thoughts above, this will also be a big problem for image fields that are used for populating galleries, carousels, etc - you can't rely on editors to not use this option and it will currently result more than one version of the same image being output. Thanks!

Sorry for the confusion - I was looking at the wrong server. The server in question is running 5.3.29 so it's simply an issue with using $this in the anonymous functions (not allowed in 5.3) you are using, so should be an easy fix.