adrian

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.

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.