Leaderboard

@szabesz has to be the most generous here on the forums. Look at the given count, and that is since the end of 2015!

@wish-fulfillment In your site tree look for the root page and in the settings tab look which URL it has for russian (your default). It should be (ru) However, I noticed that it is a bad practice to modify the default language (english) with language files. Instead you should add russian as an ADDITIONAL language and then set the guest user to this language (for the frontend) and also your admin user, so the PW admin is also in russian. Made the same mistake as you on a big site (although it works) and now it is too much work to change it. Edit: This is not the case anymore

Maybe the earlier members will remember this one from 2014: What results in very nice reactions like Today the newer IP-Board has something like this already included. The only thing, that I would change today, is to add the given reactions of the top posters to the overview screen. Until today I have not known that this gets displayed when you click onto ones reactions sum.

Thanks for your answer Robin! Your solution is one of the paths i might take. And thanks for those links! Which basically lead to a solution by Soma saving info in the session variable. Another Idea I haver is to add a url param to the Add New button (also mentioned in a github issue by @Macrura), to have information about the page within the modal, and maybe that way, I would just need a hook on Page::added and getting the "pagetable field owner" through a input->get->owner_field. What's your opinion on this? I'm not entirely STUCK on pagetables, but I like better the way they render (RM is too bulky) and also seems more straightforward to bring as pages to display on another lister. (tho I know i could do this with repeater pages too, just doesn't seemed to me like the best way to go about it). EDIT: I have something like this working now: (credits to @Macrura who also posted a similar idea in a github issue, so gave it a shot): EDIT2: Simplified hook for pagetable add new button markup edit. Thanks @Robin S! $wire->addHookAfter('InputfieldPageTable::render', function ($event) { if($event->object->name == "asignaciones"){ $markup = $event->return; $markup = str_replace("&context=PageTable", "&context=PageTable&field_parent={$event->object->hasPage}", $markup); $event->return = $markup; } }); wire()->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); if($page->template == "asignacion"){ if($this->input->get->field_parent){ $owner = $this->pages->get($this->input->get->field_parent); if($owner->id){ $owner->of(false); $owner->asignaciones->add($page); $owner->save('asignaciones'); } } } });

Update version 006 - 11 May 2019 Finally got a bit of time to work on this module. Changelog Namespacing: ProcessWire 3.x Support only from now on. Removed the module's CSS and JS files. They are unnecessary. Switched to $files->render() instead of wireRenderFile(). Option to check for and optionally use InputfieldAceExtended for code highlighting in the PHP custom code textarea. Thanks to @adrian , @diogo and others who suggested this. Option to specify number of rows for the PHP custom code textarea (@note: for some reason, it's not working with Ace Extended. It does work with plain textarea). Removed the option (in field settings) to search for files to render under /site/modules/FieldTypeRuntimeMarkup/ as these could get overwritten during upgrades. Refactored code to prevent unnecessary re-rendering of output, thanks @adrian Render PHP file mode is now supported for frontend use as well, thanks @Noel Boss Changed license to MIT. Please note this is the new master and is available in the modules directory. Screenshots Over to you @bernhard ?.

Inspired by this thread with a little nugget based on AOS by @benbyf to visually distinguish development systems from production ones, I wrote a small module that does the same and lets you adapt colors and text. Link to the github repo: AdminDevModeColors Version 0.0.1 is still very alpha and only tested on PW 3.0.124. Description This module lets you change the color for the top toolbar and add a small piece of text for development systems, so you are immediately you aren't working on production (and vice versa). The adaptions are made through pure CSS and applied if either the "Enable DEV mode" checkbox in the module's configuration is checked or the property $config->devMode is set to true in site/config.php. Works with Default, Reno and Uikit admin themes (though probably needs a lot of testing with different versions still). Since a screenshot says more than thousand words... Production system (unchanged): Dev system (Default admin theme): Dev system (Reno admin theme): Dev system (Uikit admin theme): Feel free to leave any feedback here and report any problems either in this thread or the github issue tracker.

@draganthanks, I must have been logged in, was not aware of that, I checked on mobile and indeed it was still very snappy, thanks again. @wbmnfktr thanks for thinking along, much appreciated.

Just installed Login/Register/Profile module, created a page reference field and a select options field to test, added both fields to the user template and the module settings, added the module code to a template and it worked. Maybe me screenshots help in some way.

.....And @LostKobrakai the "stingiest" among the so-called top posters ??.

I love their idea of minimal code and uncluttered but yet customizable tools. I recently set up a machine with Linux again to find out if I could establish a more solid workflow than on Windows. After several tests I finally decided to go with Ubuntu 19.04 and the Gnome desktop. It works pretty well so far. On another way way older machine I run Manjaro with i3 and hopefully soon some suckless tools. It's amazing how well that old Thinkpad X201 performs with that kind of OS.

@alemachado processInputAddPages is a hookable method, so you can make a hook without modifying the core. Also, make sure that all languages are active on parent page where you add pages from the page reference field, I'm not sure that it gonna help/

WOW

I LOVE suckless tools. Especially their terminal. @wbmnfktr are you a fellow Linux user?

Hello, you need somthing like this?

You might want to ask @kongondo what the requirements are to join his project: https://processwireshop.pw/ There are similar threads too, like:

Maybe I don't really understand your problem here. The default language itself is english but as soon as you install a language pack to/into the default language it's (in your case) russian. Or french. Or finnish. From then on it's business as usual. Have you ever used ProcessWire before? What's the main issue you are facing right now? The overall functionality of ProcessWire maybe? My PWBRecipes profile has english as default, too. That won't help you.

Btw, mainly for @bernhard and @adrian who have previously looked at RTM code, InputfieldRuntimeMarkup now behaves similar to many inputfields in that it gets its values from the Fieldtype's wakeupValue(), i.e. from $this->attr('value'). The previous implementation seemed a bit unclean to me when I looked at it recently. We had the inputfield doing its own eval() or wireRenderFile(). Now I've moved everything to FieldtypeRuntimeMarkup plus added a small helper class in there to handle such things. All the inputfield does now is serve values, as inputfields are meant to do.

Update: Blog 2.4.3 Changelog Added method to find embedded images for use as featured image(s), for example. Thanks @Karinne Cyphers How to use the method findEmbeddedImages($markup, $limit=1). $blog = $modules->get("MarkupBlog"); $posts = $pages->find("template=blog-post,sort=-blog_date,limit=10"); foreach($posts as $post) { // get only one embedded image // $embeddedImages = $blog->findEmbeddedImages($post->blog_body); // get 5 embedded images $embeddedImages = $blog->findEmbeddedImages($post->blog_body,5); // if embedded images found if(count($embeddedImages)) { // do something with $embeddedImages array // simple array where each value is a URL to the embedded image } } As you can see, the $markup is not limited to blog_body. Module has been updated in the modules directory.

In this week’s post we’ll shift focus a bit and take a look at the latest version of FormBuilder (v38) just released today. It ends up being a fairly major release with a lot of new additions, optimizations and updates— https://processwire.com/blog/posts/formbuilder-v38-released/

This looks fabulous! Saw in your screen the example for selling digital fonts. This looks great. A question: will it be possible to give a variant (let’s say: Font Italic) an option to sell it with different license types? Mostly you have something like: Licence 1 = 1-5 User, Price X License 2 = 6-20 User, Price Y And when do you think is Padloper 2 ready to take off? ?

Quite correct ? Migrations are supposed to be immutable files, so running them always yields the same effects. This is best accomplished if those migrations are managed in one central place by the entity affected. Nothing outside should implicitly be able to affect what migrations do. Having migrations in modules however does exactly that. If you update a module the migrations in it might be updated, which is not good (it might have already been executed in prod with the old code and later migrations depending on the new code might fail). Even having immutable migrations in the module might quickly become a burden as each new user must be moved through all „mistakes“ and „changes“ as well before being migrated to a final state needed by the most current version. While I‘ve talked a bit about the mentioned downsides I also think modules should come with migrations, but in a different form. There should be generators, which generate migrations in the central migrations folder of the site using the module. They imho should always just generate the most recent version of migration needed. If a module does change the way to update old clients should be by having migrations to update from e.g. V1->V2. Those could be put in another generator or even just be put into a changelog. New users of a module wouldn‘t need to care about it, they directly get migrations generated for V2, existing users can leave their existing migration for V1 in their system and just add the update migration for V1->V2. This way one can have the benefits of modules supplying migrations to users, while not having the downsides and a imo simpler option for not needing to keep track of all the old stuff already changed till eternity, especially for new users, which really don‘t need to care about old versions. One last benefit of generation of code is that it‘s editable by the user. Like I could add localized labels to a field generated for a certain module, without any extra effort needed by the module creator. Another example might be adding additional fields to a template a module uses/creates, which might be needed just on the single site. This is also a downside, as editing could break the functionality, but I think it’s a quite clear danger and one can always generate the file(s) again to get to a working migration. Edit: One last point. Migrations in modules like they're intended by @bernhard can work as well. I hope it's clear that most issues I pointed out above are about control, the one for the actual system using the migrations. I'm not keen on automatic stuff happening, which could break my system. Others might be happy to let module creators be in charge of not skrewing things up. On the other hand control means more responsibility, like changes in versions are a little bit more work for the module user.

I told you Vivaldi a is good browser ? I wonder how you picked it, did you spot it on this nice tree? ?

Welcome to the forums @mjut You need to use $config->scripts->add() for JS and $config->styles->add() for CSS .These need to be added before the controller.php $config->scripts->add($config->urls->templates . "scripts/admin.js"); $config->styles->add($config->urls->templates . "styles/admin.css"); // this comes last require($config->paths->adminTemplates . 'controller.php');

There are so many ways to skin a cat in Javascript, especially considering how far Javascript has came in recent years. You really don't need jQuery at all. It is also good to learn the Javascript core as to expand your skill set as well as remove a dependency on your project. Some of the posts here are way out of date and verbose. Native Fetch is much better than XMLHttpRequest, and there are some polyfills online if you need IE11 support. fetch('../my-url/', { method: 'post', body: JSON.stringify({ test: response.test }) }).then(response => { return response.json(); }).then(json => { document.querySelector('#output').innerHTML = json.test; }); Read more here: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API And there are a bunch of good basic examples here: https://github.com/mdn/fetch-examples/tree/master/fetch-json

https://github.com/nefe/You-Dont-Need-jQuery

@Soma Directly setting the value doesn't work, even though I would like it to do so. $field = $fields->get("optionField"); $options = $field->type->getOptions($field); $page->optionField = $options->get("value=myValue")->id;