Leaderboard

You may or may not know the templates created over at Styleshout.com. As a fan of the work I decided to create a site profile based on the latest template Sublime. Just in case you ask: I talked to Erwin from Styleshout about the idea and he was totally fine with it. There are no major changes compared to the official version of that template - just some CSS tweaks. The whole site profile was created without any 3rd party ProcessWire modules and comes with sample (lorem ipsum) content and free stock photos. Details about used fonts, scripts and images can be seen over at the Sublime template details page. If you decide to use this site profile please keep in mind that you keep at least the Styleshout link in the footer of that page - my link can be removed. ? Is this site profile ready for usage? Sure. It will work and can be customized and updated with your content straight away. There is even a SEO tab if you want to play that Google-game. Right now I would say it's more of a good looking easy entrance to the ProcessWire world. All template code is quite verbose and easy to understand for beginners. By now all site profile files are located over at Github: https://github.com/webmanufaktur/pw-sublime That's all Folks - feel free to play around with this site profile. Let me know what you would do different or what should be changed. Bugs, questions, anything? Let me know. Screenshots Pages or sections created in the backend. Choose and sort those sections for the front page. SEO if you want Auto-generated navigation based on sections. Global settings What will or might come in the future? I plan to create more site profiles in the future - all based on pre-made HTML templates that are available for free. If you know other templates or would like to see one of them as a site profile, please let me know. Maybe I can spare an hour or two.

Every time this topic comes up I'm slightly worried about the relation between any community-led documentation project and the new(ish) API reference at https://processwire.com/api/ref/. This already gets (somewhat?) automatically populated based on the latest core release, and I seem to remember @ryan mentioning something along the lines of updating / releasing a new cheatsheet that would use same data. If that's really the plan, it could easily make any manually updated documentation obsolete. That being said, I'm not 100% sure that this actually was Ryan's plan – or even if it was, is that still true? Additionally it might take a long time before he gets there (he's a busy fellow, after all.) Would be great if the man himself could chime in and let us know what the current plan regarding the docs is, and if we can somehow help make that happen ? One problem with the current, auto-generated docs might be that (as far as I remember correctly) the code that generates it is also powering the (commercial) API Explorer module, which could make Ryan somewhat hesitant to share it with others – which is perfectly fine, of course, but could also mean that we can't do much to help him there. But anyway, this is mostly just guessing. I've been quite happy with the new API reference, with the main problem being that one can't switch between core versions. For us who manage and work on different ProcessWire versions (for me this means everything from 2.2 .to 3.0) that's a major downside: currently when I'm working on anything other than my own projects, where the core version is generally speaking always the latest one, it's much easier to forget the docs and dive into the codebase to see which methods were available at the time.

Hello If you like, you can now download a demo of this "setup" or "snapshot". I think it's "ready enough" to try it and to see what you think. Donwload this installer file (Duplicator), put it in a web root and rename it to "installer.php" http://pwdev.square7.ch/download/installer.php.txt Put this zip in the same web root http://pwdev.square7.ch/download/2018-06-13_16-03-08-localhost.package.zip Call <yourweb>/installer.php and follow the instructions. An empty MySQL Database is required. If everything went smooth, you can log in as "admin" under /processwire using password: agu3j$Fh832a Then edit "home". You can add, delete, move, resize, dialog-edit and inline-edit the items (colums). At the bottom of the page, you will find "Grid Settings". There you can define which breakpoint will be changed when using wysiwyg resizing. This may be confusing if you change a breakpoint which does not correspond to your current screen width, because nothing happens visibly. You can hover over each element to quickly see the column settings. Some basic understanding of the Boostrap 4 Grid System is recommended (Link provided in the dialog). If you would like to change the german text in the demo, just select "Deutsch" where you see "Default" in the backend nav (AOS Feature). This demo is not about "stunning" design, it is kept as simple as possible showing the options which are there. If you would like to change the design, there is package.json in the root folder which should install everything you need. "npm install" is your friend. ? In "/site/templates/scss/shared.scss" is the sass-code shared by front- and backend. There would a be lot more to say, but I think this is enough for the moment. It's a demo, don't use it for your customers atm. ? Have fun!

SOLVED case 'FieldtypeFieldsetPage': $rdata = []; $rdata["label"] = $field->$label ? $field->$label : $field->label; foreach ($field->repeaterFields as $i) { $l = wire('fields')->get($i)->$label ? wire('fields')->get($i)->$label : wire('fields')->get($i)->label; $rdata[$l] = $p->$field->get($i); } $pdata[$field->name] = $rdata; break;

Disregarding the viability of using _callMethod() here: While I understand that ProcessPageView is awefully structured for hooks – I tried to make it work with a testing framework last year – I'd not suggest you calling getPage from your hook if you don't intend to replace the whole execute function. getPage() is not safe to be called multiple times, because it does modify global state and therefore does not return the same value on multiple invocations. Also I doubt searching for the called page multiple times would be good for your page response times anyways.

Yep, just saw the comments and version ? missed that from memory… How about setting up a workflow: If @ryan adds new features etc. he'd notify a mailing-list and whoever has time could add the stuff to cheatsheet? How could we breath life into it again? Because I think it's already great, it would just need some more love ?

The cheatsheet is PW based. Theres vesion added and comments. Theres couple members having access to it, but nobody seems to have time or care.

Hello everybody. Last night (no sleep) I was thinking about the state of the PW documentation and Cheatsheet in general. How about we relaunch this project, make it open and PW based? There seems to be so much knowledge and doc buried in Blog Posts and added in newer Versions of PW but Cheatsheet and Docs don't seem to reflect these… So i thought about building a new version with the following: New Cheatsheet based on PW Open for contribution by community, the PW community is so great, I think we could keep it uptodate with community effort… Indicate what Version a feature was added Comments on features etc. Links to Blog Articles, PW Weekly & useful Forum entries Example Implementations Hooks and Hook Recipes Maybe open API? What are your thoughts? Any ideas about how to implement stuff? Am I the only one who regularly finds himself tracking down blog-posts, poking for infos in the forum, comments inside files etc? I'd be happy to kickstart and support the project…

@pwFoo, if your page/template/file exists only to give some AJAX response then another approach you could consider is to hook ProcessPageView::pageNotFound. Then you don't need the page/template/file. In /site/init.php: $wire->addHookBefore('ProcessPageView::pageNotFound', function(HookEvent $event) { $url = $event->arguments(1); if($url === '/your-special-url/') { $event->replace = true; $event->return = 'your response'; } });

@pwFoo, note that you will also need to disable FileCompiler for the template. That's because FileCompiler forces the $config->paths->templates path at the start of the filename you set for the template, resulting in an invalid path if you used a full path outside of the templates folder for the filename. See here, here and here. You could open a GitHub issue for this - Ryan may or may not agree that it constitutes a bug.

you should be able to set the file that the template uses at runtime, so wherever you render the page: $page->template->filename = '/path/to/file.php'; or $t = $templates->get('some-template'); $t->filename = '/path/to/file.php'; quoted from here:

Exactly what I was looking for! It's just a back-end login, but I want it to look nice, just in case someone accidentaly finds the login page. Thanks for your help, problem solved! matsn0w

try this one: $page->social_activity->sort("-created")->slice(0,10);

Yep, that's the only way I know of to customise the comments module.

There are no guarantees that Gitlab or any other providers won't do that either. If people are afraid of snooping, they shouldn't check-in code to a 3rd party provider in the first place.

Hey @Robin S - I have been experiencing this again too. I though it was solved in some Tracy core updates, but apparently not ? I tend to agree with you that there really isn't a need to move the bar, so I think a fixed option is probably a good idea, so I have added it in the latest version - the option is called: "Fixed Position". You might need a hard reload after changing this to see the effects. This version also includes some more MySQL info in the Diagnostics panel. It's all about the current number of connections etc:

yes, since you create the inputfields, they support all built in attributes, so you'd just need to set those attributes in your PHP or JSON array. Yes, each settings page is full access controllable.

Hi @adrian, I'm still experiencing the issue below in the latest Tracy: I can fix it with the CSS I mentioned earlier... ...but it would be handy to have that as an option built into the module so no custom CSS is needed. Thanks!

IMHO building your prototype with PW gives you a solid base from which you can go in every direction. You can build just a part in Vue and let the Vue app grow over time. There's a little bit of effort involved to tie PW's pages, fields and templates and Vue templates together smoothly without a lot of overhead, but an experienced Vue dev should be able to wire that up quickly and in a reusable way (Vue would be my choice there as well). Exposing PW pages and limited write actions through ajax isn't hard to do either. It's also a walk in the park to migrate PW content into less normalized "external" tables with a small bootstrap script if performance really requires it, so unlike other CMSes where you have all kinds of different things (posts, pages, parts, whatever) in different structures, you don't really lock yourself in with PW. I agree with @LostKobrakai insofar as that there are in fact a few areas where a custom tool will get you further, like if you need a full-blown discussion forum. The choices there are rather limited if you want a good integration. Invision (the software this forum runs on) seems to be rather straight forward in that regard. I have tried my hand on a phpBB3 integration module and while the basics mostly work, it's really a PITA in some parts (like outdated examples and misleading documentation) and I've run out of time to get it into a really usable shape. There are probably a few Laravel forum components I've never heard of that can get you most of the way as a half way option. I think that will be the hardest part to decide, where will PW (or any other CMS or own development, in fact) ever only be the second best choice compared to a single purpose tool you can integrate.

Well, on the long run we expect highly dynamic content as @BitPoet has described it. I say expect, because with communities you really never know. That's why we are planning for a MVP and two pilot cities to start with. My skillset is limited, I'm actually a Scrum PO and not a software developer in the first place. So after the MVP will be a decision, either to stay with ProcessWire and get help by experienced developers as freelancers, or to employ a development team and build a custom system according to our needs. Even for building the MVP some freelancer help will be needed, I think. The reason why I asked long term questions here is: If we know upfront that ProcessWire will not be the long term solution, we would setup the VMP in a way that the backed can be replaced while keeping the frontend (e.g. let ProcessWire deliver content via REST and build an independent Vue.js client as frontend). That would be more effort and an anti-pattern for MVP where you always want to take the shortest path, but we are also considering this approach.

.test https://webdevstudios.com/2017/12/12/google-chrome-63/ https://en.wikipedia.org/wiki/Top-level_domain "RFC 6761 reserves the following four top-level domain names to avoid confusion and conflict.[18] Any such reserved usage of those TLDs should not occur in production networks that utilize the global domain name system: example: reserved for use in examples invalid: reserved for use in obviously invalid domain names localhost: reserved to avoid conflict with the traditional use of localhost as a hostname test: reserved for use in tests"

@dragan, @bernhard, @Doug G Thanks for answers. Flushing of DNS records helped and now it works with $config->sessionFingerprint = 2; As for .localhost - I have chosen it as it was reserved for local testing and dev scenarios. Is there better domain name for local development?

Thanks for adding this feature! It might be good (just to avoid any confusion) to exclude the skip trash option on the delete tab of ProcessUser because the deletion there is permanent by default.

Version 1.3.7 is uploaded. Big thanks to @matjazp, this update is largely based on his excellent work. Changelog skip unnecessary redirect on modal save (by matjazp) new "page-add" action to add child (requested/contributed by matjazp) use monospace font in module settings field styleOverrides (by matjazp) new setting: disable loading FEEL CSS (requested by matjazp) remove system templates from module settings JavaScript callback updates and documentation several minor tweaks

Default session lifetime is 86400 seconds. You can change this to any value you want. // config.php $config->sessionExpireSeconds = 86400; Allow/ disallow sessions (and the wire cookie) under conditions. Remind that you need this to have access to the backend admin. // config.php $config->sessionAllow = true; If you want to disable cookies only for the frontend /** * config.php * if we would use cookies only for the admin area * */ $config->sessionAllow = function($session) { // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // otherwise disallow session return false; }; If you want to use cookies respecting EU Cookie law I recommend Cans Module MarkupCookieConsent in combination with this settings. /** * config.php * if we would use cookies only for the admin area * */ $config->sessionAllow = function($session) { // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // user accepted cookies due to EU law (Module MarkupCookieConsent) if(!empty($_COOKIE['eu-cookie'])) return true; // otherwise disallow session return false; }; Use the core module SessionHandlerDB to store session vars in the database. Learn more about session setting options and sessions by reading the comments in the files /wire/config.php or /wire/core/Session.php of your processwire installation.

The funny thing is, ProcessWire works like this for the exact same reason: to reduce loading of not needed modules If you really, really want to do this yourself, then you would have to create a container inside the main module (or create a new module), that holds the relationships (this can even be a module configuration field). Then each "sub" module registers themselves as a conditionally loadable module with the main module. This would be done inside their ___install() -method. Then in your main module's init(), you fetch all the registered "sub" modules and load them. This would work - I can even write you an example. But to be honest, I'd just autoload the damn the module Though just let me know if you still want an example of what I described.