Leaderboard

You can do this with a few lines of JS (function(){ let inputs = document.querySelectorAll('.InputfieldWrapper .Inputfield'); [].forEach.call(inputs, item => { let input = item.querySelector('[name]'); if(!input) return; let label = item.querySelector('label'); if(!label) return; let inputName = label.htmlFor.replace(/(\w+)_(\w+)/, '$2'); let span = document.createElement('span'); span.style.display = 'inline-block'; span.style.color = 'tomato'; span.style.border = '2px solid'; span.padding = '0.25em 0.25em'; span.margin = '0 0 0 0.25em' span.innerHTML = inputName; label.appendChild(span); }); })(); Run this in Developer Console on your browser and you'll get this To automate this, you can put this script in a JS file in /site/templates/admin/labels.js, and enqueue it inside your /site/ready.php // /site/ready.php if ($page->template->name === 'admin') { $config->scripts->add($config->urls->templates . 'admin/label.js'); }

Hi All, I know I've been distant, but work has kept creeping up on me and I simply haven't been able to commit time to continue work on Jumplinks 2. At this stage, it's difficult to tell when I'll be able to continue, but I do hope it will be soon as I'd like to deprecate v1 as v2 is already so much better. Again, truly sorry for the delays...

From the marketing point of view there is a strategy called "product bundles" which means you put at least one product which is very well selling into a bundle with lower selling products to increase the sales in general. Maybe thats the idea behind this. But its only a thought. I am also interested in buying just on or two modules, which I am really interested in. I am not ready to buy the whole stuff at the moment.

I've been also thinking about the topics raised above by @abdus and @rick coming up with similar ideas. We do not know how well the current business model performs currently, but I also suspect that lowering the license fees might boost sales "a bit" somehow. I'm also having trouble finding the way to justify the price of these "bundles" and I'm also interested in parts of them or better yet in a "life time" developer license which should cost more, but would be worth it in the long run. As of @rick's idea: those developers who give most to the community should be rewarded this way. For example @adrian (probably among others, he is just one prime example) should get all these licenses for free I think, being the most active free module developer, and he is also one of the most active "forum support personnel", so to speak. Such valuable community members should be rewarded somehow, I think. I also like the idea of contests so that others can contribute too when they have the time. Edit: I forgot to mention that I do already have a license of ProDevTools, which I don't use too much just yet, but it was a way of "donation" I can afford currently.

Use AdminOnSteroids and enable Field and Template edit links, then hover on field label to see field name in a tooltip, or edit on click.

Only the native include() function does implicitly share variables with included php files. Any userland functions/methods cannot do that, which is why $files->include() cannot do it as well. $files->include() is there, because it's aware of processwire's filecompiler, if you don't need that you can simply use include() as well.

Adding the setlocale statement is not a hard requirement, but you'd need to live with the pw notice each time you log in. It's been added not because of anything related to multi-language sites, but because of issues with file handling of processwire involving utf-8 characters like cyrillic ones. These can happen on all processwire sites not just multi language ones.

I dont know how they work internally, whether they depend on each other, but I'd love to be able to test and buy RepeaterMatrix or Multiplier or Table (or any other) module individually. Whole pack of ProFields modules seems awesome to have, however, being able to buy one for ~$30 --instead of all for $130-- sounds much more affordable and this way I could buy the whole pack part by part in several months and wouldn't think twice. But $130 at once, I can't really justify it (and still havent been able to) just as easily with low (to none) disposable student income. Or instead, having sales one - twice a year would be great as well. One advantage of this change would be allowing more people to buy -> support the development & community -> give feedback -> improve these products. This could also potentially pose a disadvantage where requests from people would increase the headache and time required to respond to all these requests, but this community is more than able to handle that. I'm sure there's a reason to why these modules are sold together, and I'd love to hear your side as well, @ryan, (and all other maintainers). Regards, Abdus.

I like the idea of a periodic sale of various products. Also, Have a quarterly or semi-annual contest open to all community non-staff members to develop the best ProcessWire widget. The winner gets the designated product license, second place gets the "All I Got Was This ProcessWire T-shirt". Seriously. Having the ProcessWire logo on items would be great. I'd buy the coffee mug now.

Hello @Zeka! Sorry for massive delay but I just quickly tested EMO with built-in cache and was able to repeat yor issue. Cache file had emails as plain text and both EMO scripts were missing. On a public page it was still allright (emails obfuscated) so I don't know why it wasn't really using cached version? Switch to ProCache worked as excepted - cached page, which was obfuscated. I'm really lost with PW built-in cache since I'm so used to work with Ryans ProCache module and it has never had any issues running together with EMO. So for now my best bet for you is to get that - in a meantime we'll see if there is something we can about this. Multilanguage support is already in my TODO list, if I just could find the time... Thanks for the notice!

Okay, after some remote debugging collaboration with @Timea over Teamviewer, it turns out there was a typo where he/she created/renamed the comments field to Comments and tried to render it using $page->comments where he/she should've used $page->Comments instead. After renaming the field back to lowercase comments, error was fixed

$pages->addHookAfter('saveReady', function($event) { $pages = $event->object; $page = $event->arguments(0); //check if on template if($page->template == 'item') { //is the checkbox checked to add children if ($page->add_children == 1) { //get the values in the page field type field foreach ($page->page_assignment as $child) { //if selected pages have childen if ($child->numChildren > 0) { //loop through those children foreach ($child->children as $grandchild) { //set values. $page->page_assignment->add($grandchild); } } } } } I figured it out. Two things to change if anyone is looking to do the same. 1. Use the right hook. saveReady instead of save. 2. Add the page object. $page->page_assignment->add($grandchild);

I'm using this function in places, seems to work well: /** * Given an email address render the obfuscated version * * @param $strEmail - an email address * */ function createMailto($strEmail) { $strNewAddress = ''; for($intCounter = 0; $intCounter < strlen($strEmail); $intCounter++){ $strNewAddress .= "&#" . ord(substr($strEmail,$intCounter,1)) . ";"; } $arrEmail = explode("&#64;", $strNewAddress); $strTag = "<script type='text/javascript'>\n"; $strTag .= "<!--\n"; $strTag .= "document.write('<a href=\"mai');\n"; $strTag .= "document.write('lto');\n"; $strTag .= "document.write(':" . $arrEmail[0] . "');\n"; $strTag .= "document.write('@');\n"; $strTag .= "document.write('" . $arrEmail[1] . "\">');\n"; $strTag .= "document.write('" . $arrEmail[0] . "');\n"; $strTag .= "document.write('@');\n"; $strTag .= "document.write('" . $arrEmail[1] . "<\/a>');\n"; $strTag .= "// -->\n"; $strTag .= "</script><noscript>" . $arrEmail[0] . " at \n"; $strTag .= str_replace("&#46;"," dot ",$arrEmail[1]) . "</noscript>"; return $strTag; } also works well in a hanna code, and doesn't require any additional js files

Thank you. I've found this thread for understanding why it is not in the core: https://processwire.com/talk/topic/10691-pro-modules-where-is-pw-heading/

I do not have the time to present an exact solution, but I think it is worth to mention that @Robin S came up with something similar using Hanna Codes (it uses the description field for such purposes, but should work in any admin themes):

I'm running into this too, with my Webmentions module on a fresh install (the FieldTypeWebmention I based a lot on this comments module). Best I can tell, the issue seems to be that when you add a field, getDatabaseSchema is called for the first time. Since there is no $field->schemaVersion set at that point, it tries to run the first ALTER TABLE query before the field's table has been created. Update: I think I've found a solution. In getDatabaseSchema I first set a boolean: $table_exists = in_array($field->getTable(), $this->database->getTables()); Then any schema upgrades can be inside an if/else conditional: if ( $table_exists ) { # update to schema version 1 if ( $current_schema_version < 1 ) { # perform schema updates } } else { $field->schemaVersion = self::SCHEMA_VERSION; $field->save(); } I'm also tracking the current schema version in the class constant SCHEMA_VERSION. Hopefully this helps other developers. Feedback is welcome!

I came up with this idea for amigo.today. It's something like tinder, but for social events. User provides age and city name during sign-up, the I'm using Google API to set geolocation based on the city name/street (that can be updated later in profile). There is also age filter (max difference in age), and gender is mixed to not making it dating site. Every event last max for 7 days, after that they vanish. Users can join events, and after that they can review amigo. More recomendations results in bigger green recomendation bar. Leaving opinion without recomendation result in excluding user both ways (they can't see each other events). If there is no events you can always search by tags on the left side (categories) for last active user in that category (created/joined event in that category) and contact that person (and.. messaging system is not yet perfect). Events wall. Event page. It's not yet ready. I'm not skilled enough to finish this. I'd be happy if someone would like to join this project. Thanks!

Hi, absolutely possible. My thoughts about your points - just some recommendations and very rough ideas: Front end member registration, password retrieval, etc. You may want to check out this: http://modules.processwire.com/modules/frontend-user/ Though I have never used it before. It is quite easy to build your own registration process (once you get the idea how PW works) Regarding this, and regarding everything else, this is a must read I think: Also: Front end thread creation by all members (I assume each new thread would be a separate "page") I would add something like a user role "member". These users are allowed to create threads and post. Then, I think I would only go with one datatype (template) for all the posts. Give them a page-reference field "reply_to". If the field is empty - it is the beginning of a thread. Otherwise you will have a handy reference to the preceding post. Also a page reference like "initial_thread_post" which always references the beginning of a thread could be handy to easily group the posts in threads. Some inspiration: <?php // get the beginning of a thrad $pages->get("template=post, initial_thread_post=$threadNameOrId, reply_to=''"); // find all items of a thread $pages->find("template=post, initial_thread_post=$threadNameOrId"); Front end member profile editing Yep. Just a page / template with that ability. See "Create simple forms using API". Picture upload required to create each new thread About picture upload: Google it, I think it has been asked here before. "required" - absolutely possible. Picture upload optional on all subsequent comments inside a thread Sure. Front end post and comment uploads restricted to images only – .jpg, .gif, .png Sure. Appropriate security to prevent uploading malicious files disguised as images Hm - complex topic I guess, not necessarily related to processwire? https://www.owasp.org/index.php/Unrestricted_File_Upload Optional tagging of each thread as it's being created Automatic SEF urls created based on the thread title ( e.g. http://site.com/forum/title-of-my-thread-12345 -or- http://site.com/forum/12345/this-is-title-of-my-thread ) Already kinda processwires default! : ) You also can change the name of a page (will be the url name) to anything you like. See "Create Pages using API" Sitewide search feature Look it up here in the forums / on the site. There is at least one thread and / or one tutorial! Happy coding

You won't be modifying core files. You'll be working on translation files. From the top dropdown menu, go to Setup > Languages > [en/de] > Core Translation Files > Find Files To Translate > (pick language support module) > Submit > replace the values

This week we've merged the dev branch to the master branch for ProcessWire version 3.0.61 master. This replaces the existing master version 3.0.42. What's the difference between 3.0.42 and 3.0.61? Quite a lot! In fact, we might usually call this a major version and just name it ProcessWire 3.1, but we're saving that version number for when we get at least the new Regular site profile included (and perhaps the new admin theme), after Uikit 3.0 is out of beta. In this post, we'll cover some of what's new with ProcessWire 3.0.61 relative to the previous master version… https://processwire.com/blog/posts/processwire-3.0.61-master/

Adrian, I don't think that does what was asked. $fields will will get all the fields that you created, not the ones that are in the pages. hsanabria, you have to identify which fields represent other pages. Using your example: foreach($page->fields as $field) { $fieldValue = $page->get($field->name); echo $field; foreach($fieldValue as $innerPage) { // if value of the field is a page array, we can iterate it foreach($innerPage->fields as $innerPageField) { $innerPageFieldValue = $innerPage->get($innerPageField->name); echo $innerPageFieldValue; } } } Of course it would be much simpler to create a general function that iterates the fields of a page and call it recursively if that field is a page array. But I hope this serves as an example.

I understand and know this, but why do you need to get the translation when it is just already there. It will output in the language the user views the page ($user->language) This works just fine in the language the user view the page. echo $fields->get("body")->label; Edit: ah, hm it does not? Ok it doesn't get translated as with page fields. Since it's meant to be used for backend context there's no language value for fields settings. So you either use a $lang variable like this: $lang = $user->language->isDefault() ? "" : $user->language->id; // Default needs no id echo $fields->get("body")->get("label$lang"); Or a little hook to add method to the $fields template API var. // from template or a autoload module $fields->addHook("getLabel", null, "getLabelLang"); function getLabelLang($event){ $field = $event->arguments(0); $lang = wire("user")->language->isDefault() ? "" : wire("user")->language->id; $event->return = wire("fields")->get($field)->get("label$lang"); } // now we use it and it will recognize user lang echo $fields->getLabel("body");