Leaderboard

I've also been struggling with this: Thats because the $page you want to check is the first argument of the HookEvent, so you need to apply it there, not at the first part, which is the class (or object). You can also do this:

Hi @BrendonKoz Are you developing a custom module? $(document).on("pw-panel-opened", function(e) { console.log('opened'). }); This works for me. Where do you place your code? As for columns, it works for me, but only when screen larger than 1745 px. In this case, the width of the panel gets larger than 960px @media (min-width: 960px) .uk-width-1-5\@m { width: 20%; } Default width of pw-panel is 50%, but you can use ' data-panel-width='60%' or ' $button->attr('data-panel-width', '100%');' to tune the width, so you will get columns on smaller screens.

The language pack is available at https://modules.processwire.com/modules/german/ or in the github repository https://github.com/jmartsch/pw-lang-de/releases/tag/latest The master branch will (try to) be up to date with the most recent stable version of ProcessWire. The dev branch will (try to) be up to date with the most recent dev version of ProcessWire. If you find any missing translations or errors, please create a PR or submit a bug/improvement. I hope we as a community can work together, to update translatations as soon as a new dev branch is pushed. Please let me know if you want to translate a new dev version, so we are not both doing the same task. If you want to help, you can clone my ProcessWire environment for language packs which provides an easy way for translating a language pack. You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository. This is a boilerplate which could work with any language, but right now it is tailored to the german language pack. Then I am able to quickly release an updated stable language pack when a new ProcessWire stable version is released. Big thanks to @Nico Knoll and @yellowled for their initial work on the translations.

For some reason enabling the device mode in the Chrome developer tools logs me out of the ProcessWire admin. I'm using Windows 10, Chrome 70.0.3538.102. Steps to reproduce: 1. Login to PW admin. 2. View the site frontend in a new tab (e.g. Home page). 3. Open the Chome dev tools, enable device mode, and reload the Home page: 4. Switch to the admin tab (where dev tools is not open) and reload - you are now logged out. Can anyone else confirm this? Is there a setting in the dev tools that would avoid this? Or is this logout behaviour something that could/should be fixed in the PW core?

Just from the bit of reading I was doing, each device has a different HTTP_USER_AGENT and therefore the sessions no longer match (between chrome and the device agent). A solution someone came up with on stackoverflow was to store the user agent in the session and check against it once the switch has been made. Perhaps someone better than I could give a better way to handle it in a PW sense. https://stackoverflow.com/questions/45532678/chrome-toggle-different-devices-view-destroys-the-session

Hello @spacemonkey95, sorry for not being helpful, but you could build your own logic with: Language API Multi-Language Field Values However I would recommend you not to do this. Having a translated website with no different URLs is bad for SEO and in my opinion a bad user experience, because the user always would have to switch first for having the right language. If you really want to do this, maybe someone else has experience with this. ? Regards, Andreas

The item you want to give special treatment to is the last item in the WireArray, so you could use pop() to get that item and remove it from the WireArray: Alternatively here is a more flexible approach that you can use for any item in the WireArray:

Hi @Zeka, yes I'm developing (or trying to anyway ?) a Fieldtype/Inputtype. I'll have to do some more testing with the columns to see what might be the issue I'm having (thanks for showing me your example). I'm also going to upgrade from Master to Dev to see if it makes a difference. I tried your version of the jQuery call and it worked - the first time the panel opened. Successive opens were not getting logged. So it seems I'm targetting the wrong element in my call (as your code example will run any time any panel is activated), but why it doesn't seem to run on all of the actual events is strange. (Edit: Firefox was kindly aggregating similar console.log results for me and I didn't notice.) Hopefully the Dev version will show further success. ?

Normally this is what you should do: make sure templates are set to "HTTP or HTTPS" – which is the default – on the URLs tab and certainly not to "HTTP only" in .htaccess, uncomment the rules under "9. If you only want to allow HTTPS, uncomment the RewriteCond and RewriteRule lines below." and yes, a properly installed SSL is a must ? recommended: also make sure you do not have any hardwired or third party http URLs

The .gitignore is meant for the processwire project a.k.a. core development. For your own projects you'll need to change it to accomodate your needs.

There's no "page" argument to Inputfield::render, but you can use the property $inputfield->hasPage to retrieve the page associated with the Inputfield. The returned page is the individual repeater item page, not the page being edited. If work_detail_images is in the same repeater, the following line should be enough to get things working: $page = $event->object->hasPage;

This is how I've done it, hooks to the rescue. Clean. $this->addHookProperty('Language::code', function(HookEvent $event) { $lang = $event->object; $event->return = $lang->name === 'default' ? 'en' : $lang->name; }); So now you can access it as a property of languages. $user->language->code;

Yep. It's a really great library.

https://github.com/processwire/processwire-issues/issues/704

A couple of small updates to the Adminer panel / process module. 1) It is now restricted to the database for the PW install. Previously you could access all databases available with to the PW DB user. If some of you out there don't like this change, let me know and I can make it optional, but I think it's a better default (cleaner and a little safer). 2) It's now possible to uninstall the Adminer process module and it won't be automatically re-installed each time you upgrade Tracy - @Rudy was concerned about this with his setups. Obviously if a user has superuser access they can still install if they want, so it's more a case of removing something tempting for users without sufficient skills, rather than being a true change to security. On this note - Adminer is restricted to superusers (same with the Console, Snippet Runner and File Editor panels).

Aha! I've worked out how to do that now, by adding the 'permission' item in the getModuleInfo array. I didn't see that in the tutorial ? , which is excellent BTW.

Recently Bitrix (a popular commercial CMS here in Russia, known worldwide for its Bitrix24 CRM/PM/... solution) introduced similar functionality they called Site Constructor. This thing allows to build pages or parts of the pages from pre-defined blocks which can be static or dynamic. Site developer can style, modify or add their own blocks. They recommend this for landing pages for now, but are aiming to move all content management to those blocks. So there is some trend. I actually do use (almost) the same approach in PW. Most of my pages have content-page template with content_blocks Repeater Matrix field holding most of the content in repeater items. What is missing in my solution is: the easy ability to restrict the order, allowed types of those items (though possible with this module); the ability to easily move/duplicate content blocks from project to project (still think Repeater Matrix should be PageTable Matrix); the ability to easily preview the page built (like with this solution) in admin / edit it inline on the frontend. I see this way of building content very flexible, but still somehow unfinished. We have all the parts in PW to build a full-blown page bulder that will not allow too much for ones that do not need it, but will make it easy to build something really complex and interesting without programming. But those parts are not yet combined in a polished solution. I would certainly like to have it in PW (as a PageTable-like PageBuilder FieldType/Inputfield combo, probably).

I've a prove of concept S3 filesystem module based on flysystem and the core inputfield file running in a project of mine. I'm not comfortable to put it out in the public, but there are ways to make it work. Personally I'd try to avoid mounting remote filesystems, as there's more networking involved: client <-> server <-> S3. I'd rather work with direct s3 urls for the frontend.

AOS also has this tweak: https://github.com/rolandtoth/AdminOnSteroids/wiki/FileFieldTweaks

Happy to assist. I think it would be a good idea to give very clear and easy instructions of how to help. Something like a little tutorial that guides us step by step through the process from finding an un-translated word to creating the PR. Thanks for taking this project over! ?

This was on old post. Actually, what I do is fresh install processwire on the server. When I get ready to upload my project, I dump my local mySQL database, switch to the online site where I drop tables and import the database. After that, I uncomment about 3 lines of code in my index.php file that changes the processwire admin password in the database. From there, I just login and also change the passwords for any other roles that my be set up. Ryan pointed me to the info about setting the passwords via the PW api. In the past I used phpMyAdmin to dump out the database, now I use the dbbackup() module, save the backup file, then switch to processwire on the server and use dbbackup() to import the dump.

These redirects can be made by uncommenting two portions of the PW .htaccess file: One Two If you're seeing this when trying to access the PW admin then it could be due to old browser cookies - try clearing the cookies for your domain.