LostKobrakai

PageTableInline is really the thing I miss the most about "repeatable" parts of pages. Directly followed by settings to change its behavior like from multiplier to textareas profields. Either free adding of blocks, but maybe limited in number, or a fixed number of them which can be labeled, e. g. a page with three profiles (image, headline, text) and being able to call it like this: echo $page->profile_1->text; echo $page->profile_2->text; echo $page->profile_3->text; Funnily I've not used repeaters for a bit of time now, they are kinda useless for most of my usecases.

This would be great, especially as one doesn't automatically follow topics. But the link you both posted doesn't work anymore.

I could imagine the module hooking into the new "variations" modal window or a own dedicated modal like the core one. I never really liked the fact, that the imagefields presentation was changed. With Thumbnails I had breaking admin theme styles and now it's a new core function made unavailable. Additionally, it would be nice if CroppableImage could also recrop api generated crops from the variations modal. Of course only the ones restricted in height and width.

If chosen is not working is should report this back, so I should be able to just unhide the textarea to allow adding of pages. Edit: Just pushed a commit to add this. Now you can at least add pages. Will take a look at the fork later.

There's already a github issue about this, but sadly no feedback by now. https://github.com/ryancramerdesign/ProcessWire/issues/914

I don't think you could use the highligher standalone, as is has to work different for a editor enviroment compared to a more-or-less static <pre> tag.

That the statement on the projects page. I've just tested it on safari and it's not loading, so maybe chrome in iOS isn't properly detected as mobile browser.

Code highlighting is done by javascript, to theres no simple "echo $page->codeHighlighted". I'd also think it's better to leave the choice for a highlighting library to the user.

I'd support that. Just drys out the process. Especially if you need more than one type.

Saving (already existing) pages is as easy as updating a hidden multiselect field with "selected" properties. If you're not really using the features of asmSelect, why use it then? Have a look at this http://jsfiddle.net/b7ty2Lud/1/. It's using simply InputfieldSelectMultiple. Then you can do everything else like you'd like it to work/look. You could also have a look in InputfieldPageListSelect about generating the markup for your rows. It's not like just updating a single line, but on the other hand your free in your markup.

Until the magic is finished there's this: http://modules.processwire.com/modules/textformatter-image-tags/

I would suggest you take a look at ProcessTemplate::buildEditFormFields. It does use the standart asmSelect, but with additional information rendered. Then you could pack the "config" stuff in a modal window. If you want to stay with the inputfield inside the asmSelect I would suggest creating a seperate inputfield for it, so you can style it to fit your needs. Currently one just sees, that it's kinda hacked together from asmSelect, but it doesn't have to be such a small bar to be dragable.

name is the url part of the page, so it should be unique for children of the same parent. That's why I used it.

Shouldn't be to hard to do. The example module and maybe this thread https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ , if you need forms, should get you there. The rest is just the standart api. Also keep in mind the option of locking the archived pages. This way after your done, no one can accidentally change the archive.

This error means, that there is somewhere some field, which has two entries with the same id, but the id should be unique. In your case this id is "41-0". FieldtypeMulti means it has to be a multi value field. In my cases it's mostly the fault of some custom module, but could be anything else, too.

If you're cloning the team and player pages to be archived, these maybe get cloned to a subtree /2014/… . The problem is, the team pages' pagefields do still point to the original player pages, as the field just saves the id. So you'd need to have some way to also change the pagefields to point to their newly cloned playerpages. Something like this. // $page = teampage foreach($page->players as $player){ $page->players->remove($player); // Get the same player but the archived one. $archived_player = $pages->get("name=$player->name, has_parent=$page->parent"); $page->players->add($archived_player); } $page->of(false); $page->save("players"); If you're comfortable with building small modules I would even suggest just packing all the logic in a Process module, where you just choose the year to be archived and press a button and everything is getting moved and changed automatically. It would at least be more fail save, than doing it by hand somehow.

I think the best way would be to archive the whole tree or at least the branches of data that need to be archived, e. g. player and team pages. Then you can update the normal part of the page and save the cloned archive pages and maybe lock them to be uneditable. You'd just need to write a "archive process" so the pagefields are not only cloned but also updated to reflect the now archived playerdata.

Admin pages are best build as modules, but this will get you started in adding custom php to a backend page http://modules.processwire.com/modules/process-admin-custom-pages/.

It seems it's not a reusable function. The pagetree and lister variations do have completely different markup, only a class for the styling is the same.

There's no option for this in the core, but you could hook page::saveReady to change it, if it's not the id. The problem about creating the page with the id in the url is, that before the page is actually saved it has no id, but it has to have a name. So you really have to do this after the page creation.

You could either use a dedicated tempate for this page, enable pagination for it and let you javascript call the sites: e. g. /search/page{1, …}/. Then just use the pagination like everywhere else. Or you do implement the pagination calculation yourself, so you don't need to change the url. I don't have the details in mind, so maybe you need to adjust the numbers to fit the difference of counting from 0 or from 1 and you should check it the page even exists. See the example above for more on that. $limit = 5; $start = $limit * $input->post->pageNum; //get this from the ajax call $paginatedPages = $pages->find("your=selectors, limit=$limit, start=$start");

There are different options for the table. By default all fields are entity encoded, but you could change this do insert own html code in the table fields. $table->setEncodeEntities(true|false); $table->setSortable(true|false); $table->setCaption(""); $table->setClass(""); // Add buttons after the table // same as for rows "label" => href $table->action($array); As for the best way to integrate this: Modules are more way more flexible and process modules are there for exactly that reason.

Why not take the one hanna code uses. Shouldn't be to hard to adapt this to a standalone inputfield for textareas.

Edit: Somehow I had something crazy and wrong in mind with this. if(count($pagearray) > 2){ $last = $pagearray->pop(); echo $pagearray->implode(', ', 'title') . ' & ' . $last->title; }else echo $pagearray->implode(', ', 'title');

Here's an article about it: http://www.smashingmagazine.com/2015/02/03/redefining-lazy-loading-with-lazy-load-xt/