LostKobrakai

I've it working already, but yeah did exactly that.

That was exactly the right hint. I don't think so. In my eyes these big callback wars are a wast of time and asyncron code would deserve a easier way to manage stuff. Instead of pasing data though a shitload of callbacks, it would be so nice to be able to just return stuff after it's done. In a way, that the callback just "resumes" where it left.

Can somebody help me out with some Javascript, which I can't get my head around. I know the theory about closure and callbacks, but how the heck can I have something that reports back after multiple callbacks are all finished. Now I know again why I dislike node so much. I'm trying to build a local html-only page, that uses openstreetmaps so to add latitude and longitude to a csv table based on the city. Getting it to call the rest api of osm is easy, but I can't figure out, how to spit out the new csv after all those calls are done. function getGeoCodes(jsonFromCsv){ for (var i = json.length - 1; i >= 0; i--) { //AJAX requests and adding the lat / lon to the json object } // After everything is done reformatToCsv(json); } Edit: Also I'd like this calls to be parallel and not one after another.

They're already usable, they just wheren't intentionally developed for that. Only documentation is lacking, while Soma's topic and the comments in the mentioned core files do already cover most of the information, just not in a very easy-to-enter way. And there's still FormBuilder, which does provides a grafical ui for setting up fields (and lots more).

A small improvement would be using the saveReady hook, as it's fired after the to-be-saved data are checked for errors.

wireRenderFile() / wireIncludeFile() are new shortcuts to the old TemplateFile markup used in the blog profile. They were introduced somewhere around 2.5.0, so they're to new for the blog profile.

Why don't you just build a textformatter instead of fiddling around with some hooks? These can be very simple compared to what the hanna code module looks like. Here is one I build recently: http://pastebin.com/Tc1sHvD2. I just don't know if this will play well with your vision of mixing and matching language fields with your own translation stuff. I can't really see, how you want this to work, as it seems like this stuff "{TR:Teil}: xxx.yyy.zzz - {TR:Gehäuse}" shouldn't be part of each language's text, but still kinda be part of each one.

That's why these files are kept. You could always exclude those hidden ones from uploading or git, but having at least the last version available can be useful. The think the only way to get to those older dev versions by yourself would be cloning the repo and moving the HEAD (git) to the last commit before the version bump.

Use the CoreUpgrade module. It doesn't remove anything, but just hides the old wire folder / index.php and .htaccess. To roll back just rename/delete the current ones and change the hidden ones back, like so: .wire-2.5.17/ to wire/. In github there's no way to have these versions displayed as ryan does not "mark" them as releases which they really aren't. The version number just comes from some core file, where it's hardcoded.

The function that gets hooked by the module (Page::editable) does exactly what it sounds like. Return if a page is editable by the current user. Page::addable is the function to control the ability to add children. Essentially you'll need another function addable(), which does the same check for users as editable, and in init() a second hook to Page::addable which points to your new function.

This API was never intended to be used by developers other than for modules, that's why there is little documentation besides the thread you've mentioned. The best solution would be taking a look at the files itself: wire/core/Inputfield.php & all those wire/modules/Inputfields/*.module. Most of them do have a fair amount of comments, so you should get along after some time. P.S. It would be nice to ask such questions in the thread it belongs to.

From the api you can just use these as with all options available: https://harvesthq.github.io/chosen/options.html. $inputfield->setChosenOption('no_results_text', "Text"); $inputfield->setChosenOption('placeholder_text_multiple', "Text"); $inputfield->setChosenOption('placeholder_text_single', "Text"); I don't know if that's enough for you to hook ::render and inject these. Regarding the Tab / Enter situation. I'm quite good in js by now, but the sourcecode of chosen is still somewhat complex. The last time I searched I didn't find a way to check if there are still elements left in the dropdown or not. I'll take another look into it tomorrow.

Than my theory was wrong, never had to check where sorting is actually saved. What will always work is if you use this blueprint https://processwire-recipes.com/recipes/extending-page-save-process/ and add the code to clear the cache when specific pages are saved.

The problem you're strugling with is keeping repeaters and pages seperate. You're searching for pages with at least one repeater item, which has created_for checked. You either need to only search for repeaters $repeaters = $pages->find("template=repeater_wwww_slider, created_for=1, include=all"); // repeaters are hidden by default foreach($repeaters as $icon){} or you need to check in the foreach if the current repeater's checkbox is checked. $somepages = $pages->find("selector for your pages with repeater"); foreach($somepages as $somepage){ foreach($somepage->wwww_slider as $icon){ if($icon->created_for == 0) continue; // Your stuff } }

I would suggest that, too. Espeacially for a "Royal" enviroment correct quotes and dashes should be used. While the use of different quotation (”“»«, not " ') marks is mostly an aestetic choice, besides cultural preferences, there are rules to the useage of different dashes and the hyphen. I can only speak for the rules in the german speaking area, so I would suggest looking at local rulesets. But for Germany the version with hypens would be plain wrong, at least from a typographical standpoint, and the one with the large dash would also be a suboptimal choice, but not as bad as a hyphen. The large dash is kinda old school and originates in price labels like so: 19.—€. That would be the historicly correct usage, while it's todays usage is more like a gimmicy eye-catcher.

The api way would be not using array notation but one of these. $page->repeater->first(); $page->repeater->eq($i); $page->repeater->last();

If you mean sorting in the page-tree than it should work with clearing on page save. The new position has be be saved in some way, which should trigger the cache clear. It can only be, that it's only the parent page which is saved, as the children are sorted.

Take a look at this thread, it's about timespamps, but these are integers, too. https://processwire.com/talk/topic/7918-find-most-efficient-solution-for-storing-multiple-values-in-a-field/

Seems like I've got the first job thanks to the developer directory

A pagetables behave exactly like a page field with multiple pages. It just looks different. So $row_page is just a page object like $page or $pages->get($someSelector).

It seems like you've changed stuff around, so the error messages aren't really helpful. I can't be sure if the line the error comes from is still the line in your code above. But it looks like that there is html code where the parser is expecting php code. So maybe adding a "?>" in front of that line could help, while it normally shouldn't be necessary for included files.

Maybe try to enable debug mode (in /site/config.php) and see if there are any errors.

Are those files in the same folder? Also did you try include("header.php"); without the ./ ?

This shouldn't matter, it's not fixed until it's converted to markup by $form->render(). But I've noticed that InputfieldCheckbox overrides this on its own render() function. I've already added a github issue about that. So maybe there something alike this in your case.

Oh, I didn't know that not everybody can reopen issues. I can understand that. But on the other hand there are lot's of fixed issues, which are still open. There are issues which are open for month now. There are mayor version jumps in between and, at least for me, it seems nobody is there to check if they're still relevant or fixed in any later version. Also I noticed, while writing the intro post, that there was still a pullrequest of mine open, where it was kinda clearly stated, that it'll never be merged because of clear reasons. Another example are multiple pull requests about hashed tabs, which are already part of processwire by some time. It's not about closing down feature requests or discussions but to mostly close things which are just done in some way.