adrian

Hi again Ryan, I attached a draft of the module I am working on. It works, but at the moment still requires that I make setFilename hookable. And it also suffers from the fact that this is hook is triggered on page saving, as well as file upload. I thought about going with InputfieldFile::fileAdded, but that has the problem of not renaming until the page has saved and of course would cause problems with immediate embedding in an RTE before page save, among others. If you test it you'll see that in the module config options you can limit the module to specific templates and pages (and their children). You can also define the format you want to use for naming files using something like: mysite-{$page->path}-{$page->id} or anything you want really! I would also like to add the ability to define different formatting options on a field by field basis. The problem is that I can't figure out how to get the current field when hooking into Pagefile - any hints? I was thinking that maybe a better approach would be to make this module an alternate Inputfield type that could be selected from the field's detail's tab. This would solve the per field formatting options. Maybe have a site/field-wide default format in the module config settings and a separate override format option in the field input settings. Will think about this some more. On reflection not sure this would be a good idea since it would mean it wouldn't be possible to use other Inputfield types, like Antti's cropimage for example. Any ideas? ProcessCustomUploadNames.module

Another small update. Images now have "video-" prefixed to their filenames. This allows the images field to also store user uploaded images, in addition to the video images. When the module checks for videos that are no longer present on the page, it will no longer delete images that the user has uploaded, unless of course they happen to have "video-" in the filename as well. Hopefully this is a reasonable approach to this. Let me know if it causes anyone any problems and I'll revisit.

I really love rsnapshot: http://www.rsnapshot.org/ It is still command line and uses rsync, but handles all the incremental backup setup for you. Just setup and call from cron!

Hey Soma, Is this the same as my issue at: http://processwire.com/talk/topic/383-module-import-pages-from-csv-file/?p=43443 I submitted a fix and pull request for that here: https://github.com/adrianbj/ImportPagesCSV/commit/ad4d9e71f844fe2e4c9162152177e119a403ef38 Although it sounds like you have something else going on with the $pageName as well.

Hey Ryan, I am already so used to the fields and templates submenus - so much quicker getting things done! Small suggestion - do you think it would be too much to have an Add New item at the top of both those submenus? One other thing and this might make things messy, but I wonder would it would be like if it is was possible to select a template when creating a new field, so that as soon as you save the field, it gets added to the template automatically. Just an idea and maybe not a good one

Hey Ryan, What am I missing with hooking into Pagefile::install ? I can't for the life of me get it to trigger. Is there anything special I need to do with this? EDIT: The only way I could manage to hook into Pagefile was by making setFilename hookable. It seems to be working fine like this, but if you get a chance, would you mind looking at this, as I think I must be missing something with install. Only catch seems to be that it gets triggered every time the page is saved, as well as when the file is initially uploaded - is that expected behavior?

Is it just me, or is the "View" tab a little strange. I feel like this has been discussed before but couldn't easily find it. I just wonder if maybe it should be moved from its location next to the other options, and/or made to not look like a tab. At a minimum, I think it should open the page in a new browser tab so the user doesn't potentially lose their edits if they haven't saved yet. Maybe it's just me

Hi Peter, I am using 5.6.13 without any problems!

Really looking great - minimalistic, but without removing functionality - such a rare thing these days, I am impressed! Two comments for the moment - the field and template drilldowns are great but I wonder how functional they will be on a site with a lot of fields - it might be become to unwieldy to be useful - not sure if it should be configurable so it can be turned off or not. I also wonder whether there needs to be the ability to scroll within the div that contains the fields, rather than scrolling the entire page to get to the bottom of the list - maybe that will be messier? I think you actually just fixed the rounded corners issue, although I do think the css for the menu could still be tweaked a little - being very pedantic, the grey border that appears around the fields and templates items when you are viewing the sub items looks a little clunky - I think just keeping the background grey would be better. Also note that go from a fields/templates submenu back to its parent doesn't return the parent to the grey background. Also, maybe just a personal preference, but I'd rather see the submenus slightly offset, rather than slightly overlapping the main dropdown - just a little breathing space. A couple more minor things - I love the futura colors, but worry about the use of that much red - seems to me that it diminishes the use of red in error messages. I will also iterate one of Soma's earlier comments about too many colors - buttons in particular seem too colorful with many changes between states, including a red border when active but the mouse is no longer hovering. BTW, removing the title really is a great improvement - it's looking so clean now PS: Even though I said less colors, I would like to see a warning color (orange i guess) for appropriate messages like this one: ProcessTemplate: Pages using this template are not viewable because the template file - I see that there are different shades of green, so maybe that is ok? PPS: Any thoughts on making the "Add New" link a config option - I think on some sites this will be great, and on others perhaps confusing to certain users.

Nik, This will fix the "There is no Thumb called" error: https://github.com/somatonic/PageListImageLabel/pull/1 I've leave Soma to answer the other part.

Just a couple of related links, in case you haven't seen them: http://processwire.com/talk/topic/2700-new-pw-project-notification-and-approving-page-changes/ http://processwire.com/talk/topic/2024-page-draft-module-useful-to-anyone-please-feed-back/

Hey arjen, I don't suppose you solved this did you - I have having the same issue - looking through the DB tables I am yet to find anything obviously different from a repeater created via the admin vs one created via the API - will keep looking, but am hoping you might already have the answer EDIT: always the way - as soon as you post, you figure it out - the entries are missing from the fieldgroups_fields table. Hopefully should be easy to sort out!

Sorry Manol - I don't have formbuilder, so I really don't know how it works, but maybe this post from Soma might help: http://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/?p=30979 EDIT: Speaking of the man himself

I think your issue is not the hook, but rather the: $form->get("reconocimientos") It is not an object. I am not really very familiar with hooking in templates, but I just tested this and it works: <?php $page->addHookBefore('Page::loaded', null, 'errorTest'); function errorTest(HookEvent $e) { error_log('testhook'); } so I think you are on the right track, but you need to sort out your form object. Are you maybe using FormBuilder? or do you have $forms defined elsewhere in your code?

nghi - don't bother - just grab the lastest dev version of PW - Ryan has implement toggling of grid and list views for images - very nice

Just added support for being able to return a page based on a selector, eg: //populate the results frame with the page returned by the selector. You must use $getpage as the variable! $getpage = $pages->get(selector); EDIT: Just added a code fix (in the included template file) and requirement for using $getpage as the variable to populate to avoid conflicts with normal code execution.

Just updated module with support for the ACE editor module so there is now syntax highlighting if you have it installed. EDIT: Also support for populating the $out variable, rather than echo'ing out the content directly if you'd prefer (either works). You can change this to a different variable in the code_tester.php file.

This module is obsolete - please use the Console Panel in Tracy: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console Ok, this is really not very fancy, but I think it will come in quite handy - for me at least It provides an admin page where you can test code without the need to edit template files. It runs from a new item under Setup called "Code Tester" Simply enter your code, including an opening <?php and click "Run Code". Page will refresh with the code block still in editor, and with an iframe containing the results of your code below. In some cases the output may not be relevant if your code is manipulating pages etc via the API, rather than outputting content to a page. Then you can easily make code changes and run again. Github: https://github.com/adrianbj/ProcessCodeTester Installation Install as normal, then move the included file "code_tester.php" to your site's templates folder. Depending on your sites template structure, you may want to edit this file. I have set it up using the head.inc and foot.inc approach that is used in PW's default profile. There are detailed instructions in the file to make it easy to modify as needed if you prefer using a single main.inc or other approach. Install the ACE Text Editor module if you want syntax highlighting. That's It! How it works Nothing very high tech - when the module installs it creates a new template: code_tester and a new unpublished page: Code Tester. When you click "Run Code" it creates/updates this file: /site/assets/files/ID_of_Code_Tester_page/code_tester_code.php and writes your code to the file. This file is included from the code_tester.php file and the code is run and the output processed. Note that I am using ob_start(); include; $out = ob_get_clean(); so that this will work take the approach of populating variables that are output within a main/shared markup file like main.inc If you want to use a variable other than $out in your test code, you will need to edit the code_tester.php file accordingly. Things you can do It may not be immediately obvious as to some of the things that work with this, so here are some examples: echo 'test'; $out .= 'test'; //list page titles matching the selector foreach($pages->find(selector) as $p) $out .= "<li>$p->title</li>"; //populate the results frame with the page returned by the selector. You must use $getpage as the variable! $getpage = $pages->get(selector); // bulk delete pages matching the selector foreach($pages->find(selector) as $p) $p->delete(); So really it is more than a code tester - it can also be used as a way to test selectors and return the resulting page and also as a way of running admin maintenance scripts. Hopefully you guys might find it useful. Please let me know if you have any thoughts for improvements.

Hey horst, I just tested Soma's code with the sorting set to none and it seems to be working fine. The new page was added to the top of the children, but I could still manually sort without any error. I am running the latest dev - maybe a couple of days old. Let me know if there is any specific scenario I can help you test.

Hi Radek, Sorry - I think my reply may have come across wrong. I was not suggesting that localization support shouldn't exist at all. I think it is very important! I guess my reason for mentioning that I don't have a use for it was to emphasize how impressed I am by your efforts, even though they don't have direct benefit for me in the english speaking world. I have played around with localization a little in PW in development of some modules, which is why I pointed to that thread on distribution of module translations - I think it is important that this becomes easier and standard. Hope I didn't offend in any way.

Or, if you have access to PHPMyAdmin (or similar), you can look in the pages table for the "name" of the row with an "id" of 2 PS I think you can safely change the "name" field to whatever you want which will of course change the URL.

Personally I really have no need for language translations (although perhaps I should - maybe it is a typical english speaker's arrogant oversight ), but I am still amazed at the work you have put in on this. It does make me think we need to revisit this topic though: http://processwire.com/talk/topic/2583-delivering-module-translations/

I haven't tested Soma's solution, so not sure about those bugs, but do you need manual sorting in the back-end after creation? If not, wouldn't Ryan's suggestion of setting the sort order to "date created" in reverse work for you? I am guessing you do want the manual sorting, but thought I'd mention it, just in case

I asked Ryan about this module and he is happy with it going in the modules directory, so I have submitted it: http://modules.processwire.com/modules/process-redirect-ids/ It is fine to have it run on all your pages/templates (the default), but don't forget to check out the module config settings where you can limit this. Remember it is only called by pages that return a 404 so I don't believe there should be any overhead on normal page loads. So please feel free to start using it and let me know if you have any improvements you'd like to see.

Just been thinking about joshuag's original aim and wonder if it could be tackled from a different angle. I know I often have the instinct to categorize things in the page tree to make them easier to find when editing, like in his example: /blog/ cat1/ article1 article2 cat2/ article3 article4 I usually refrain because I want the simpler URL structure on the front-end and it can be hard to know what category is really the most important when an article belongs in multiple categories, but it can make browsing through pages tedious when you have 100's or 1000's of articles. What I wondering is if there might be a way to group and sort the pages into categories in the tree view based on a chosen (and easily changeable) field value (most likely an ASM field that points to a list of selectable categories). I see this as being somewhat analogous to the way we can add tags to fields to have them appear grouped on the Setup > Fields page. Not sure the best way to implement this - maybe it could be a module - I'll think about it more soon - maybe even put together a mockup of what I think it could look like. Imagine being able to instantly group and sort the page tree by year and month, and then switch to subject, keywords, categories, or whatever other field you want. Any thoughts?