adrian

Nice one ESRCH, but that only affects the View tab on editing a page - I also like to change the view links on the page tree. Yours does cover the only critical issue as that is when it is possible to lose changes to a page (unless you have Soma's Form Save Reminder installed). I just posted this over at: https://processwire.com/talk/topic/7588-admin-custom-files/?p=89331 because it uses Martijn's Admin Custom Files. This version also changes the view links on the page tree. ProcessPageList.js $(document).ajaxComplete(function(){ $('li.PageListActionView a').each(function(){ if($(this).attr('target') == undefined){ $(this).attr('target','_blank'); } }); }); ProcessPageEdit.js $( document ).ready(function() { if($('#_ProcessPageEditView').attr('target') == undefined){ $('#_ProcessPageEditView').attr('target','_blank'); } }); Maybe someone else will also like this approach.

HI Astatek and welcome to the forums. By default, image fields can contain more than one image, so they will return an array of images, even if only one is uploaded. The simplest option is: $agent->images->first()->url but if you choose to change the setting on the image field's Details tab - "Max Files Allowed" to 1, then you could remove the need for the "first()". You can also adjust what will be returned when formatting is on by adjusting the "Formatted Value" options. You should have a good read through http://processwire.com/api/fieldtypes/images/ to get a better understanding. Hope that helps.

Thank guys for this module - it was great to quickly set up a ratings system. A couple of thoughts though. I am not sure why it needs to be an autoload module - I'd rather you simply load it manually in a template file when you want to use it. I am not sure why it isn't simply a custom fieldtype that can be added to templates as needed - the way you have done it seems to work just fine, but the one issue I am having is that it can't be used as easily in all situations - for example, you can't select "rating" as an option when configuring a custom view with ListerPro. I am sure there are also other situations where it would be preferable to be a fieldtype, but maybe there are advantages to the approach you have taken that I am not thinking about. Of course if #2 is implemented, then #1 is no longer an issue Any chance you'd consider a bit of a rewrite to make it a fieldtype? if not, please let me know and I'll put something together myself - just trying to avoid duplicate modules that do the same thing Thanks for considering.

Doesn't this need to be broken up into two files, or am I missing something? ProcessPageList.js $(document).ajaxComplete(function(){ $('li.PageListActionView a').each(function(){ if($(this).attr('target') == undefined){ $(this).attr('target','_blank'); } }); }); ProcessPageEdit.js $( document ).ready(function() { if($('#_ProcessPageEditView').attr('target') == undefined){ $('#_ProcessPageEditView').attr('target','_blank'); } });

I have actually started using this version so that the links only show on hover and are hidden from the parent when a branch is open: .content .PageList .PageListItem:hover .PageListActions{display:inline;-webkit-transition-delay:.25s;transition-delay:.25s} .content .PageList .PageListItemOpen .PageListActions{display:none !important;} .content .PageList .PageListItemOpen:hover .PageListActions{display:inline !important;-webkit-transition-delay:.25s;transition-delay:.25s} In addition to quicker access and less confusion, it is also a huge performance increase on slow internet connections (I just spent a few months with horrible internet) because you don't need the ajax call to retrieve the child pages just to be able to edit the page, or add a new child.

Hey Ivan, I just committed a fix, although in a hurry, so not tested, so please let me know if it works for you as expected. Actually curious why you are using $page->title rather than $page->name - wouldn't it end up being the same thing?

"Custom Script" - does that mean your code is not in a PW template or module file? Have you bootstrapped in PW so you can access its API? https://processwire.com/api/include/

For the moment, the easy fix is to create that DB field (data1020) yourself in the field_title table. Are you comfortable with PHPMyAdmin or similar tool, or command line SQL?

I am not sure if maybe this problem is back, or certain MySQL configurations are still causing issues. Here is some further reading: https://processwire.com/talk/topic/8759-cannot-add-new-language-in-latest-dev-bug/?p=88530 https://processwire.com/talk/topic/5286-switching-fields-to-language-fields-produces-fatal-errors/ I'll make sure it is made aware that this still seems to be an issue. What version of MySQL are you running?

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.