Leaderboard

I agree

I think for the whole data and user handling PW is very well suited. If it's a browser game in the classic sense, that's all you need. If you want real-time user interaction, you of course need something like @adrian mentioned. I once fiddled around with a couple of HTML5 2D game engines and found Phaser to very fast (webGL with canvas fallback), powerful and flexible. It's built on pixi (which is the HTML5 successor of a once very popular flash gfx engine, can't remember now).

Is my 100th post I wanted to do something special. I edited a video, hope you like it Just for fun Edited: Now with subtitles

Celfred, I had some of the same thoughts about Fredi and access. In that thread SiNNut mentioned above there was a simple module to hide the backend admin from certain users. By modifying it slightly I'm using Fredi without letting frontend editors see admin pages. 1. Create a role called frontend-editor and give it page-view, page-edit, page-edit-recent permissions. 2. Create a user (or several) with that role. 3. For each template they need access to, use template's access tab to grant 'edit pages' access to that role. 4. Setup HideBackend this way (a little different from Adrian's version, maybe rename it) to keep them out of backend... class HideBackend extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Hide Backend', 'summary' => 'Redirect frontend-editor user from backend admin back to site\'s homepage.', 'href' => '', 'version' => 1, 'permanent' => false, 'autoload' => 'template=admin', 'singular' => true, ); } public function init() { if($this->user->isLoggedin() && $this->user->hasRole("frontend-editor")) { $this->addHookAfter('Page::render', $this, 'redirect'); } } public function redirect(HookEvent $event) { if($this->page->template == "admin") { $this->session->redirect("/"); } } } I think I'll have it redirect to some kind of welcome page instead of "/" but this does seem to be working. The user can use the admin login page to login. Once they succeed they are immediately redirected away and Fredi edit links should become visible. Edit: Wait! - Had it working yesterday (thanks to a typo) but there's a problem with this method. The crux of it is that if we redirect in HideBackend we break fredi's uses of the admin pages too. I can't totally prevent a frontend-editor user from going into admin pages but I'm testing a workaround to reduce the likelihood of that happening. This may not be the final answer but in HideBackend's init function I'm saving the current time to a session variable each time an obvious fredi request comes in (opening the modal). Other requests are allowed if previous fredi request was not too long ago, otherwise the redirect hook is set.

I have a local version that does that. Let me see if I can get it cleaned up enough to send you.

I´m breaking blad Glad to be here again. I will make another video soon, maybe it's more serious or a joke...I don´t know.

a good one may also be this with track changes (see Somas post there)

Go to Setup->Languages. Choose a language for which you will create transaltions (by default there is only one language called default, crete more if you need them). Under "Site translation files" press "Translate file" button. Choose a file to make translation to and "Submit". Go ahead and express your super multilingual capabilities.

As a side note (and to plug my own module), If you just need blocks of text collapsed into an accordion, you can do that with a single textarea and the TextformatterAccordion module.

What about doing the same tasks using incognito mode - does it result in the same behaviour? Do you have any active extensions that are messing with the User Agent string?

Looks like missing files like js and or css.

<?php echo $pages->get('/other-page-url/')->body; ?> But maybe you should start with the tutorial: https://processwire.com/docs/tutorials/hello-worlds/

Maybe PageTableExtended? https://processwire.com/talk/topic/7459-module-pagetableextended/

In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.

$item->body, $item->title, $item->url should be $page->body, $page->title, $page->url, I think

no real-time user interaction, animations or html5 engines needed. JS could be used for moving map, countdowns and chat... these games are almost like some community website ... people play these for months or years and login in each day just to click to upgrade some of their buldings in their town which may take more than a day...

Not tested but something simular would work I guess $this->addHookAfter('Pages::saveReady', $this, 'hookPagesSave'); public function hookPagesSave(HookEvent $event) { // Modified page, already contains changes in memory, not yet in DB $page = $event->arguments('page'); // If there is a change in your field if ($page->isChanged('name_of_you_field')) { // Page as it is in the DB $oldPage = $this->pages->get($page->id); // ... Now you could do your comparison old <-> new. } }

Hey blad! You new Al Pachino (or is it jewish fundamentalist) look brought me here again)) I rewatched the awesome video and finally realized why does it end with the clip it does (at 1:13 and on). It is the default admin theme!

Hi jlahijani, Do these posts from ryan and soma will work for you as a starting point?

@LostKobrakai - I wouldn't consider "more than one person working on a site" an advanced use case. In my experience, most CMS's suffer from this problem, so it's not something that is unique to ProcessWire -- but it seems to me that for some situations, storing the *definition* of the field structures in a config or code file, while keeping the data in the database is ideal. I utilize this system with a plugin I offer for the Concrete5 CMS where designers can set up their own content field definitions via a point-and-click dashboard interface, but the results of their pointing-and-clicking is saved to a php array. The data itself is *not* normalized into separate database fields though... so there is definitely a tradeoff (the plugin I make is best suited for page content that is not queried in any context other than "give me all the content on this one page that is being viewed"), and I don't think the way ProcessWire is structured would allow for such a setup. But other CMS's do utilize this approach -- Bolt CMS and October CMS come to mind, as well as the flat-file CMS's such as Statamic and Kirby. So I'm not suggesting that ProcessWire should (or can) be changed, but it is a limitation of building an application in PW. And another reason that if you're building a "custom application" as part of the larger website, you might want to consider using plain old SQL files or a db migration library and do it the old fashioned way instead of leveraging ProcessWire's "everything can be a page" approach.

For such advanced usecases there's always the possibility to version control the json export for templates/fields. The problem of database schema changes is more a problem of relational databases and not the cms itself.

Hello, That's it!! Thank you!! Processwire is really awesome!! Regards

Hi, Oleg! Try this: $page->category->categorytype->title; I assume that you got a pagefield named "category" on you product page pointing at the category. Edit: And you should name a topic something more explicit tham just "fields".

You have to have Language Support module installed. Look here: http://processwire.com/api/multi-language-support/

Just turn off session finger print in config.php. $config->sessionFingerprint = false; Or also $config->sessionChallenge = false; If that's helping, it looks like you have permanent IP or Agent changes. Could be network related too.

I have no idea. Sorry I can´t help you, Here the same topic two years ago.

Looks expected to me. The template!=rss|home doesn't affect root page, only the children. It's the starting point, thus it can't ignore it.

Problem is, even the include unpublished is only testing the pages requested, means if the tag is unpublished or not. You can't get only tags used by published pages with a find selector. $posts = $pages->find("template=posts"); // no unpublished ones $tags = new PageArray(); foreach($posts as $post){ $tags->import($post->tags); } $tags = $tags->unique(); Note that this does not scale well with growing number of posts. The more scalable way would be hooking Pages::save and Pages::delete and unpublish tags if no other visible page is using it anymore / republish them if they are used again. Edit: And again missed the other variant $tags = $pages->find("tags"); foreach($tags as $tag){ if($pages->count("template=post, tags=$tag")) continue; // Found at least one possible post }

You can use hooks to modify the return value of ProcessPageEdit::buildForm, which generates the button. This will help you get started with the form generating api: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/.

Hey joey102030! I think kongondo's advice is necessity but not sufficiency to achieve what you need. You should add some js/jquery pligin on top of that wonderful module to make it work as accordion. You download the js plugin and plug it in the template file like any js with <script>. Than customize the plugin and/or Markup Simple Navigation output options and you're done.

My occam’s razor guess would be that PW couldn’t have anything to do with this at all, since it’s all server side, while Chrome only gets to see the final product. So it would have to be some local caching that Chrome does on its own. This admittedly dated SO thread shows a couple of settings that may be of interest: http://stackoverflow.com/questions/5690269/disabling-chrome-cache-for-website-development

The module is now fully functional again and its version number is set to 2.0.0, because it was a full rewrite. Finally it supports all sorts of crops again: cropExtra what is needed by CroppingTools north - south west | east And by x/y params and centered of course too. I updated the first post here in the thread, where yo can find the links to Github and the modules directory.

Until last week Hooks were mostly a mystery to me too...until I did this and this and got this

The argument names are the method arguments/parameters ..So, in your method foo(), there are two arguments...bar and baz....with 0 and 1 indices respectively..So, you can get with either e.g. event->arguments(0) is the same as event->arguments('bar') but the numeric index is faster (although less readable)... http://processwire.com/api/hooks/#read_arguments

I just committed big refactoring to Fredi, which fixes all the known bugs and simplifies a code a lot. I haven't tested this yet on other pw versions than latest dev, so be careful when testing. It "should" work pretty universally, since now it uses ProcessPageEdit instead of own custom processes. So image/file uploads and reordering (tested) and repeaters (not tested...) should work also.

Shame I can't like myself.

I have pretty mixed feelings about this module myself. It does work (well, there is one user where it doesn't and I don't have a clue why), but all should be aware that there are many things to consider: Complexity grows exponentially with each subsite you add. More templates, more fields, more pages Your coding needs to be different if the site is subsite: $page->rootParent isn't actually rootParent, but the home. www.campaign-site.com/processwire/ admin isn't there, it is only at www.main-site.com/processwire/ Maybe not compatible with all the modules. Ie. form builder works, but you need to create new /form-builder/ page under each of your subsites. Cross linking doesn't work yet. Ie. if you use get or find to find pages from other subsites, then echo $p->url() won't give the right url (this is should be actually easy fix, but not yet fixed) If your subsite is big, I don't think using this module is good idea. For simple marketing campaign sites I think this is fine way to go, but for larger sites I would consider other approaches.

Sessions are based on cookies, which are domain spesific. So you need some kind of single sign on solution to share sessions between the domains.