bernhard

I think tpr already fixed the menu on default theme and created an issue on github? On mobile, I can't link to it...

@adrian yes, exactly, totally missed that! @tpr now that you mention it i guess we already talked about it... not sure if you understand me right as a new admin theme would be a totally different beast. but not so important anyhow

sorry for doubleposting but this one just came to my mind: i don't know how AOS is structured at the moment and i don't have time to investigate so i'll just throw in the idea. what if the module had a separate folder and separate files for all those little tweaks and we could easily activate/deactivate the things that we need. this would have 2 benefits everybody could contribute submodules very easily everybody could build his own set of admin tweaks, for example i could create one gitlab repo for all my custom admin tweaks, install AOS, git clone my repo (or even better fill in an input field and click "pull" ) and then have all my tweaks listed with checkboxes in my AOS admin screen. if we had a concept what modules are enabled/disabled by default or the possibility to import/export settings one could really speed up development. thinking further i would also love to have a concept like that for regular modules as well... maybe that would be something for the new pro devtools...

i would - if at all - vote for a very vague implementation. maybe setting the transparency through configs... i've also observed newcomers not really knowing what to do with the pagetree. but that moment lasted for around 5sec at max until they hovered and got the concept (on reno - having to click to see the actions is a bigger hurdle).

as there is really no difference between those two modules it's definitely better to stay with robin's version. thank you @Robin S for your hint to ->add()

yeah... it would have been one of my first really helpful modules. but @Robin S was faster ^^ maybe the todo-module, if not anybody beats me again

oh noooooo then it seems i was working too much on the todo-module it's the first pw weekly i missed since a while... anywhay. it was not too much effort...

oh man... exactly the same... i knew this would happen. not enough time to follow the forum and it seems it was not on pw weekly also in this thread it was not mentioned thanks for your hint...

hi robin, totally missed your module and created my own... maybe you have more time than i have and compare them? seems yours does exactly the same than mine. maybe more efficient because i'm using nested foreach...

i created a configurable module for this:

This module comes in handy when you need related pagefields that are dependant on each other. Example: you have a sports team and team members belonging to that team. you need 2 fields: one on the team-page, one on the member-profile. this module keeps both fields in synch. Other examples would be hierarchical company structure or any other kind of membership relation. Demo: settings in this example: Gitlab: https://gitlab.com/baumrock/PagefieldPairs Modules Directory: asap only tested on PW3 and reno theme. Please test it faithfully before using it. please report any issues

works, thank you!!

@mel47 it's really easy to write any kind of custom import script so there are no limits maybe thats of interest to you

thank you tpr, makes sense sorry i had to change my code and i am using a modified page edit screen (because i have a files field and need to store files, so it has to be a page). there everything works fine. would be nice to remove the editlink limitation. i'm using lots of my fields in custom forms for a processmodule! thank you

hi tpr, i have an issue with your module in a panel frame. i created a demo process module so you should be able to reproduce it. just install the module, go to the hello world page and click "reply" when i click into the field the first line is moved down and also there is some error on top you can import the needed field here: { "rocktodos_body": { "id": 148, "type": "FieldtypeTextarea", "flags": 0, "name": "rocktodos_body", "label": "Nachricht", "contentType": 1, "htmlOptions": [ 2, 4, 8 ], "icon": "align-justify", "inputfieldClass": "InputfieldCKEditor", "tags": "-RockTools -RockTodos", "collapsed": 0, "required": 1, "minlength": 0, "maxlength": 0, "showCount": 0, "rows": 5, "toolbar": "Format, Styles, -, Bold, Italic, -, RemoveFormat\nNumberedList, BulletedList, -, Blockquote\nPWLink, Unlink, Anchor\nPWImage, Table, HorizontalRule, SpecialChar\nPasteText, PasteFromWord\nScayt, -, Sourcedialog", "inlineMode": 0, "useACF": 1, "usePurifier": 1, "formatTags": "p;h1;h2;h3;h4;h5;h6;pre;address", "extraPlugins": [ "pwimage", "pwlink", "sourcedialog" ], "removePlugins": "image,magicline", "textformatters": "", "showIf": "", "columnWidth": 100, "requiredAttr": "", "requiredIf": "", "toggles": "", "extraAllowedContent": "", "contentsCss": "", "contentsInlineCss": "", "stylesSet": "", "customOptions": "", "plugin_sourcedialog": "" } } ps: seems that it has something todo with the getinputfield method and the id... don't know whats going on ProcessHello.zip

hi ryan, first of all: great blog post! and great news! i want to start a discussion here (not at the blog post comments) as the forum is the main spot for that and has more features like quoting and so on... i want to support @Michael Murphy with his request of a solid import/export helper and setting up new projects. i've developed some parts on my own but they are far from production ready and tailored exactly to my needs and my environment. what could really speed up everyones development process would IMHO be: export/import function of complete site (not site profile!) include all data into the export (also users and wire folder) include an installer script to re-import the complete site (would be great for pulling live data easily to one's local dev environment) restore site from given dump ability to wipe all users except admin ability to set new admin password and db credentials ability to reset salt the second point would help setting up new projects quickly. i always find myself installing the same modules, setting all the settings... it would even be greater to define such installation profiles via json or the like so we could host them on github and share them. this would also be great for testing / trying out new modules: grab installer (installer.grab.pw) put in file to installer config file (eg github/xyz) set database settings install

hi ben, would you mind adding some screenshots or even better screencasts so that all of us get an idea what your module does immediately? tools for screencasts i recommend are licecap (gifs) or www.screencast-o-matic.com thank you

lol, really?! sorry for that - i have to take a closer look anyhow. but i have to use my module first some time to see what/if there is a need... sometimes in live you need a second look even on processwire i needed it - and i'm really happy i took it!

Thank you gmclelland! Found this while looking through your links. Looks promising! http://www.raymondhill.net/finediff/viewdiff-ex.php

1 minor "issue" some modules are double listed. i guess that comes from the "new modules" tab, that shows recently installed modules. maybe you can exclude them in the list? feature suggestion (thank you for the docs-links btw): i think it should be possible to have an index on top of your github readme linking to each submodule via #mysubmodule. i suggest placing only ONE link to the docs beside the main headline (as shown in my screenshot in my previous post) and then the user could click on the relevant item and images would already be loaded and the github issue should not be an issue any more. the current help-icon could be replaced by a link icon, linking to the section of the module config, where we can define the detailed options for this submodule. do you get me? i find myself a lot enabling/disabling submodules and then having a "hard time" to find the options for that submodule. thank you for this great module

glad you like it. i think ryan likes it too, as the new demo page is also powered by uikit and the roadmap for 2016 (how fast did this year pass?!??) states, that the admin may get powered by uikit as well. really looking forward to that. https://processwire.com/blog/posts/happy-new-year-heres-a-roadmap-for-processwire-in-2016/

i guess you could also to this: // if submitted $form->addClass('my-form-submitted'); and css like .my-form-submitted input { /* input fields styling for submitted forms */ }

good idea with the snippet button! my suggestion would be: case1: code that does NOT get stored anywhere echo 'no comment at first line, no save'; case2: code that goes to history, but NOT to snippets. that would be for some kind of code you need multiple times for a limited period of time (eg developing a module). you could change your code as often as you want, it would only show up ONCE in the history, saying "update module XY 1 -> 2". the list could be limited to around 5 - 10 items. // update module XY 1 -> 2 $m = $modules... $m->upgrade(1,2); case3: when you click on an icon or the like in the list of historical codes, you could make a snippet out of this code. eg "update module XY 1 -> 2 (icon: create permanent snippet)" // my awesome snippet // do stuff for all pages under parent XY foreach($pages->find('parent=XY, ... i think the snippets and codes should always show up only once in the list and hold the last executed code. if you want to apply slight modifications you could just update the comment in the first line (like creating a new branch on github) // my awesome snippet - TEMP CHANGE XYZ // do stuff for all pages under parent XYZ foreach($pages->find('parent=XYZ, ... after the change you could rename the comment and overwrite your old snippet

i think that woulb be totally enough and if that is simpler, i would be totally happy with that you brought up a new idea: what if the code restore feature that you implemented remembered the window/tab somehow? do you think that would be possible? i guess a simple solution would be to store it based on the url path in a cookie. another idea, and a short explanation why i think that this would be useful: in the last weeks i found myself often do something like this: $m = $modules->get('mymodule'); $m->upgrade(1,2); // test upgrade from version 1 to 2 $m->upgrade(2,1); // test downgrad from version 2 to 1 i then have to (un)comment one of those lines repeatedly... i think a history would be quite nice! simpler and maybe easier and more efficient than a snippet library (or similar in many cases): just put a comment in the first line and it would save it to the history. what do you think?

just for reference, i'm using a different approach on another project now: