Leaderboard

I would try the session fingerprint config setting. Start by setting it to false and if that works you can try to make it more secure after that: https://github.com/processwire/processwire/blob/36984e4a057268b7a45b848e1b3b6ee757583459/wire/config.php#L241 Obviously make the change in your site/config.php file, not the wire one I pointed to.

Nice work! Just in case you would find it cleaner, you can use this version in your site/init.php file rather than setting up an actual module. Sometimes this approach is nicer than having lots of different little helper modules. $this->addHookAfter("ProcessTemplate::buildEditForm", function(HookEvent $event) { $languages = $this->wire('languages'); $template = $event->arguments[0]; $form = $event->return; $field = $this->modules->get("InputfieldText"); $field->attr('id+name', 'seo_rules'); $field->attr('value', $template->seo_rules); if($languages) { $field->useLanguages = true; foreach($languages as $language) $field->set('value' . $language->id, $template->get('seo_rules' . $language->id)); } $field->label = $this->_('Seo rule'); $field->description = $this->_('If you want to add a custom rule to MarkupSEO'); $field->notes = $this->_('To define a variable use {title} syntax'); $form->insertAfter($field, $form->tags); $event->return = $form; }); $this->addHookBefore("ProcessTemplate::executeSave", function() { $template = $this->templates->get($this->input->post->id); $template->set('seo_rules', $this->input->post->seo_rules); $languages = $this->wire('languages'); if($languages) { foreach($languages as $language) { $template->set('seo_rules'.$language->id, $this->input->post->{"seo_rules__$language->id"}); } } });

Solved!!! Hope can be useful This is the class class SeoTemplate extends WireData implements Module { public static function getModuleInfo() { return array( "title" => "SeoTemplate", "summary" => "Module for add seo_rules field to template.", "version" => "0.0.1", "autoload" => true ); } public function init() { $this->addHookAfter("ProcessTemplate::buildEditForm", $this, "appendFieldToForm"); $this->addHookBefore("ProcessTemplate::executeSave", $this, "saveSeoRuleField"); } public function appendFieldToForm(HookEvent $event) { $languages = $this->wire('languages'); $template = $event->arguments[0]; $form = $event->return; $field = $this->modules->get("InputfieldText"); $field->attr('id+name', 'seo_rules'); $field->attr('value', $template->seo_rules); if($languages) { $field->useLanguages = true; foreach($languages as $language) $field->set('value' . $language->id, $template->get('seo_rules' . $language->id)); } $field->label = $this->_('Seo rule'); $field->description = $this->_('If you want to add a custom rule to MarkupSEO'); $field->notes = $this->_('To define a variable use {title} syntax'); $form->insertAfter($field, $form->tags); $event->return = $form; } public function saveSeoRuleField($event) { $template = $this->templates->get($this->input->post->id); $template->set('seo_rules', $this->input->post->seo_rules); $languages = $this->wire('languages'); if($languages) { foreach($languages as $language) { $template->set('seo_rules'.$language->id, $this->input->post->{"seo_rules__$language->id"}); } } } }

All sorted - I published it which actually requires: More > Move https://en.wikipedia.org/wiki/ProcessWire

I emailed with the guy that deleted it last month. I didn't get a clear answer about what the problem was, but there were a couple of old links in there that went to 404s, so I think that was part of it. It also sounds like some people helping to manage content at Wikipedia don't think that those involved in a project should be the same ones to maintain the Wikipedia page on it. I think that makes sense in a lot of cases (like for commercial projects especially), but doesn't make much sense in our case. I am aware that nearly all the other CMS projects (open source and commercial) are maintaining their own Wikipedia pages. If someone else would be interested in helping to maintain the Wikipedia page I think that would be good, so that it's clear it's a community and not just some dude in his basement trying to write a Wikipedia page for something that nobody knows about. I did make a lot of edits and removed old links, updated information, etc., but honestly can't figure out how to publish it. So it remains a draft for now. I think we may need someone that knows Wikipedia better to figure this out. But I would like to go ahead and re-publish our Wikipedia page. But how?

Some race condition on the server with a shared session directory perhaps? In that case, enabling SessionHandlerDatabase should instantly get rid of the problem. Looking closer, two of the three IPs in the log belong to cloudflare, so if you're using their CDN to speed up the site, this could be a misconfiguration there too. Is the backend routed through Cloudflare? Could it be that there's an option to preserve cookies active? I've got no experience with Cloudflare, but I have seen some very dangerous options to that extent available with Akamai.

Ok problem solved, I've found the issue. Apparently pages that have a parent or ancestor that is hidden also require you to use ("include=all") as selector, even if the page itself is not hidden. I was searching for hours on that. Thanks for your help anyway!

hey @phil_s, we already follow the rules you linked too, with a bit more individuality: look for a gamma setting shiped with the image: https://github.com/processwire/processwire/blob/36984e4a057268b7a45b848e1b3b6ee757583459/wire/modules/ImageSizerEngineIMagick.module#L225 if there isn't one available, assume default value: https://github.com/processwire/processwire/blob/36984e4a057268b7a45b848e1b3b6ee757583459/wire/modules/ImageSizerEngineIMagick.module#L230 go into 16bit mode (if available in this imagick engine. there are also only 8bit engines!) https://github.com/processwire/processwire/blob/36984e4a057268b7a45b848e1b3b6ee757583459/wire/modules/ImageSizerEngineIMagick.module#L242 now do all imagemanipulations, ... and recalculate and set gamma back: https://github.com/processwire/processwire/blob/36984e4a057268b7a45b848e1b3b6ee757583459/wire/modules/ImageSizerEngineIMagick.module#L339 and set back the colordepth to 8 or lower, if the original has lower depth: https://github.com/processwire/processwire/blob/36984e4a057268b7a45b848e1b3b6ee757583459/wire/modules/ImageSizerEngineIMagick.module#L342 But it looks like your local workflow isn't correct. I suggest to read your first link to brasseur, but in regard of Photoshop and how it should be used. Using photoshop in short: don't use "save for web"! only work in 16 bit depth mode! Everytime!! (No, - no exceptions!) At the last step, procede reduce the color depth from 16 bit to 8 bit, but only for variations that you want to share / upload, etc! KEEP your 16 bit ORIGINAL locally! If you don't have original images in 16bit, first step after opening it in photoshop is, to increase the colordepth from 8 to 16. Then do all your stuff, and at last step, reduce the colordepth back to 8 bit. For using images as a master source in PW, I highly suggest(ed) to save images in Photoshop as jpegs in 12 (=100%) quality. (NOT with saving for web, just the regular "save as jpeg" method). Don't deliver your original image in PW, never. If you need it in its original dimensions, call it with $image->width($image->width). This way, you get a variation with original dimensions but lower quality, your default image quality. Or pass an array with different quality setting with the image to the pageimage / imagesizer. EDIT: If you embedd an ICC profile or not, is not relevant. But you need to use / have the image in sRGB!! This is assumed by all web image render engines. GD, for example, isn't able to read ICC profiles. Some IMagick installations also don't / cannot.

Try this: public function init() { $this->addHookAfter("ProcessTemplate::buildEditForm", $this, "appendFieldToForm"); $this->addHookBefore("ProcessTemplate::executeSave", function($event) { $event->object->template->set('seo_rules', $this->input->post->seo_rules); $languages = $this->wire('languages'); if($languages) { foreach($languages as $language) { $event->object->template->set('seo_rules'.$language->id, $this->input->post->{"seo_rules__$language->id"}); } } }); } public function appendFieldToForm(HookEvent $event) { $languages = $this->wire('languages'); $template = $event->arguments[0]; $form = $event->return; $field = $this->modules->get("InputfieldText"); $field->attr('id+name', 'seo_rules'); $field->attr('value', $template->seo_rules); if($languages) { $field->useLanguages = true; foreach($languages as $language) $field->set('value' . $language->id, $template->get('seo_rules' . $language->id)); } $field->label = $this->_('Seo rule'); $field->description = $this->_('If you want to add a custom rule to MarkupSEO'); // Description for field tags $field->notes = $this->_('To define a variable use {title} syntax'); $form->insertAfter($field, $form->tags); $event->return = $form; }

ConnectPageFields Allows the connecting of two related Page fields so that changing one updates the other. Purpose of module An example: suppose your website is about movies. You have a template "movie" with Page field "actors". For each movie you add the actors that appear in the movie. All good, but what if you want to find results like... the 10 actors who have appeared in the most movies actors who haven't appeared in any movies since 1990 You cannot retrieve these pages with a single efficient $pages->find() query, and must load a large PageArray into memory in order to iterate or filter it. For the sake of making these types of queries more efficient you could structure your templates/fields so that movies are added to actors instead, but this may be a less comfortable workflow and can run into equivalent problems (e.g. "find the 10 movies with the largest cast"). The solution is to have a two-way relationship so that movie pages have an "actors" Page field and actor pages have a "movies" Page field. This module will keep these two Page fields in sync so that adding "Ryan Gosling" to "Drive" automatically adds "Drive" to "Ryan Gosling". Also, you can select the same Page field in both Page field A and Page field B. For example, create a "Related" Page field for related pages. Choose "Related" for both fields in a pair in the module config. Now when you add "Orange buffoon" to Related for "Donald Trump", "Donald Trump" is automatically added to Related for "Orange buffoon". Usage Install the ConnectPageFields module. If you haven't already done so, create the two Page fields you want to connect and add them to templates. In the module config select the two Page fields in a "Connected field pair" row as Page field A and Page field B. You can add rows as needed using the "Add another row" button. Troubleshooting Make sure you have set the "Selectable Pages" settings for each Page field correctly: The settings for Page field A should allow pages using the template(s) that Page field B has been added to. The settings for Page field B should allow pages using the template(s) that Page field A has been added to. http://modules.processwire.com/modules/connect-page-fields/ https://github.com/Toutouwai/ConnectPageFields Module config: Demo showing how changing one Page field updates the other:

Then you should be fine

You can read this thread :

Maybe <?php $_SERVER['REQUEST_URI']; ?

v0999 is up containing the requests posted above. - RenoTweak: fixed position of branding if sticky sidebar is on but sticky header is not - autofocus filterboxes only on module/template/field/translator list pages - do not add filter box for InputfieldTable (ProFields) - filter box: always show search icon - removed tap shift to focus main search (Hotkeys) @adrian Certainly it could, be where would the buttons (Save, etc) and the search field go then (in case of compact header)? Or do you meant it for non-compact-header mode only? Something like this could work, but there's a lot of combination that should be taken care of. I think if you need a compact header, then well... use the compact header I kinda like the header H1 as it is, it would be too compact this way.

Something like this? : Of course, the selectors and the fields must be adjusted, but as far as I understand your issue, this one should also work when dealing with dates. BTW, welcome to the forum

Thanks all. There's really a lot wrapped into this. It connects to a lot more than I'm showing here. The test server doesn't show the other kinds of help desks we have. This one is the IT version, but there are 2 other variants of this system, one of which is for marketing (which has a bunch of additional fields when you complete a ticket). The original tickets are powered by FormBuilder. That way there can be all these ticket variants without having to create or try and reuse a bunch of fields. Once the ticket is created, it's sent to a PW page. The Formbuilder JSON (and the JSON for the actual Form) are saved to the page. This way, if the form fields ever change, it doesn't effect old tickets. Essentially the state of the form and the entry are snapshot together and attached to the page. The replies/internal notes are an extended version of the comments field so that everything is contained within a single page. It doesn't have to be that way, but I had already created this modified comments field for another project, so it was the easiest way to go with this project. Anyhow, It's not something I intend on releasing at this time, but may revisit it eventually if there's enough interest. I would remove the FormBuilder dependency if I made it public.

Makes sense, thanks for the detailed explanation! Can you elaborate on what the profile check / assign @line 214/215/216 does? Is this only for checking if the image profile is Grayscale? What caught my eye initially in the brasseur guide was the following part, at the end of the gamma section: This would imply that there is a more accurate and I would guess more convenient way to do the whole conversion dance? This sounds perfectly reasonable, except for the ubiquitous "don't use save for web" caveat. "Save for web" removes the EXIF data, removes attached image profiles, reduces the image to 8bit if >8bit, and converts it to sRGB. You could create an action that does this for you, except save for web is much easier to explain to clients. FWIW since we're comparing notes: I'm using Lightroom/CaptureOne for basic corrections, further edits / archival files are 16 Bit .tiffs rendered in prophoto RGB/Adobe RGB depending on the source, which I manually convert so srgb (usually since I want to control the rendering intent of the conversion), before using "save for web" with neither "convert to srgb" nor "embed profile" checked, which leaves me with a clean jpg with no profiles or meta data embedded/attached. (I use itpc for tagging and cataloging and I don't want these to show up in the web version). Very true. This also means that with GD, any image NOT converted to sRGB will still be interpreted as such. If you forget to do this with wide gamut profiles (e.g. Prophoto) it will lead to quite funky effects

Not sure, but I think it is intentional. But also, you always can (re)order / sort it after adding a complete PageArray at once: http://cheatsheet.processwire.com/pagearray-wirearray/sorting-and-filtering/a-sort-property/ EDIT: Ok, thats not my evening. @BitPoet has already linked to PageArray->sort(), also to the newer API docs. Good night all together.

Uuh, I read wiki, and thought it was the old wiki tutorial. But it was wikipedia. My fault, sorry for any confusion!

For pages related to same kind of pages: movies (Ironman related to Ironman 2, Avengers etc), books, games, tutorials, recipes... If i write IronMan with space between the words i get V@g1n@ Monologues wtf

Probably not: I answered my own question in the next post: The situation @Wanze replied to is a little different - not an order of page IDs but an order of values to match a field against.

The find call returns the pages in the order in which they are configured to be sorted. A PageArray keeps the order in which the pages were added (minus duplicates, for which the last addition counts) unless you explicitly call its sort method. There is one exception to the rule, which is when you pass a PageArray to add() or append(). In that case, the items in that PageArray get prepended. I'm not sure if this is intentional.

In PW's multi-language handling for text-based fields, these fields don't hold a regular string (as they do in non-ml setups) but a LanguagesPageFieldValue object. This object stores the field values (strings) for the different languages. When you retrieve the string value of such a field, PHP's standard magic calls _toString on the object. The implementation for _toString is done in the hookable getStringValue method. Unfortunately, while the LanguagesPageFieldValue objects do know their page and field, the information isn't accessible from a hook. But you can always access $this->wire('page') to get the current page in the frontend. Then you can retrieve the absender through $page->absender->first(). Some quick&dirty code for the function that probably illustrates this better (the above sounds more complicated than it really is): /* ... */ $mlObj = $event->object; // LanguagesPageFieldValue object $currPage = $this->wire('page'); if($currPage->template == "doctors") { $absender = $currPage->absender->first(); $absLang = $absender->sprache; $event->return = $mlObj->getLanguageValue($sprache); } /* ... */ As long as you apply use this logic to all language fields on a template, this approach should work fine. Otherwise, it would probably get complicated.

It seems that overflow-y: scroll; on the "body" causes this, interesting. It was there to avoid page jumps but as I see it's OK to add this to the "html" tag. Add new module: thanks, I've fixed that.

Okay. Thanks

Thank you for the reply and the welcome!! I'm glad to be here. This solution works great - thank you so much for pointing me in the right direction.

Ha ha... customers eh? Budget restrictions. They have a few new features they want to implement with their remaining 2016 budget. In 2017, we're expecting to build a complete new site that most likely won't use PW. There's nothing in the pot to fix this issue. Update: I granted the Editor role the exact same permissions as the Superuser and it made no difference. I granted a specific user (originally an Editor) the additional role of Superuser, and of course it works. I don't like it, but if there's no alternative, I'll have to live with it.

Ok this is what I used in the init.php: <?php //header('Expires: '.gmdate('D, d M Y H:i:s \G\M\T', time() + 86400)); /* * Rootpages */ $root = $pages->get(1); $rootPages = $root->children()->prepend($root); $this->wire('rootPages', $rootPages); /* * Settings */ $fields = array(); foreach($pages->get("name=settings")->child as $key => $f){ $fields[$key] = $f; } $fields = (object) $fields; $this->wire('settings', $fields); /* * Translations */ $translations = array(); foreach($pages->get("name=settings")->child->translations as $key => $t){ $translations[$t->key] = $t->string; } $translations = (object) $translations; $this->wire('t', $translations); ?> I get this error: Invalid argument supplied for foreach(), the problem is that $pages->get("name=settings") returns a page, but when I add ->child it's a nullpage. While it does have a child, and just works correct in the init.php but not in the ready.php. I just make some wire objects to use myself along the whole website. For example for some settings like e-mail, phone, ... I make them accessible as: $settings->phone or $t->some_translation_key.

Thanks for the help. It's what I was looking for. <?php foreach($page->children("show.label=CTRL Daily") as $post) :?> <?php echo $post->title;?> <?php echo $post->ad_copy;?> <?php endforeach;?>

Thanks for this - I'm going to experiment more with the PageArray and methods like insertAfter(). Unfortunately I do need to delete + recreate the pages. I'm dealing with large XML data files, which are updating existing pages in PW. Not only does the XML update fields but it will sometimes not include fields which is seen as the equivalent of deleting those fields entirely. It gets complicated and messy and was agreed that deleting and recreating the pages was all round cleaner way of doing things. Not ideal I know but it works for this project.

Thanks again @Robin S - seems like you have looked into this a lot more than me I see now that the sort field in the field is actually correct, but as you said, is not available as a property from the API.

I think that's just a coincidence if you add several pages one after the other without reordering them in the field. But because a page that's in a PageTable field can reside anywhere in the page tree there could be other pages added (that have nothing to do with the PageTable field) which would affect the sort property of the page. Intentional, because there are really two sort values - the sort property that belongs to the page itself (the tree sort) and the sort that belongs to the PageTable field. This is in the PT database table but doesn't seem to be passed though as a property of the pages when you get them via the PT field. @alexcapes The order of the field is set according to the order of pages in the PageArray (or array of page IDs) when you save it to the field. For example: $page->setAndSave('my_pagetable', array(1009, 1002, 1007)); // an array of page IDs // or $pa = $pages->find("template=my_template, sort=title"); // create and sort your PageArray however you like $page->setAndSave('my_pagetable', $pa); You could also do things like get the existing PageTable PageArray and then add pages using methods like insertAfter() But are you sure you have to delete and recreate pages? You could keep the existing pages and change just about any property of them without actually deleting them. Maybe explain the whole process of what you're doing and someone may be able to suggest a different approach.

I think "sort" is the sort order of the pages as they appear in the tree, which may be different than the order they appear in the PageTable field.

Nice one! But just a small thing: you set $search to an empty WireArray and then immediately re-set it to an empty array: $search = new WireArray; $search = array(); You only need the latter.

I think you should deal with it now. Take a look at the "modules" database table via PHPMyAdmin (or similar) and see if there are in fact more than one entry in the class field/column for ProcessLogger. You should probably just be able to delete one of them to remove the error, but I would like to know why it happened in the first place. Was this a completely fresh install with a new empty database?

Did you do this bit...? But in any case if you update to LimitPageTable v0.0.3 linked in my first post above it adds a config option to choose which value you want to match against so no editing of the module is needed now.

I've actually created a working solution (which I'm sure can be improved upon but it works for now). I've made a simple module that populates a field ('edition_sort') on each PageTable page with it's order number: $i = 1; $editions = $page->editions; foreach($editions as $edition) { $edition->of(false); $edition->edition_sort = $i; $edition->save(); $i++; } I can then get this field ('edition_sort') value from the page being deleted and add it to the newly created page, then sort the PageTable by the field. It all works but I'm sure there's a much neater way of doing it!

Something like this: foreach($page->children() as $child) { echo "<p>{$child->title}</p><p>{$child->text_area}</p>"; } You can also use a selector in the children() method if you want to limit which child pages are shown, or to sort them, etc.

For me, it works perfect, congratulations.

Definitely. I was looking for something else in the forum and stumbled upon your module. It does exactly what another backup script (PHPBU) is doing, but now from within the admin panel.

Hi arjen! Yes, I am still using the module but with an old processwire install. I just never published it to the repository. Just send me the pull requests and I will recheck and finally publish the module. I did't find the time to do so when I first did it and then I just forgot. It would be a waste if it works fine and others don't find it.

Updated to v0.0.2. This version simplifies the module somewhat and you no longer need to select templates in the config.

@Jennifer Stock, I've been working on a module for this purpose for a while now. Figured it's time to finish it off and release it. Find it here:

I was wrong about the bug in PageTable - I misinterpreted what the purpose of the 'reloaded' event was. So unfortunately there's no event that's guaranteed to trigger when the inputfield does an AJAX reload. Instead we have to check the PageTable field with every ajaxComplete(). But that's not actually a bad thing because we want the check to fire if the PageTable was inside an AJAX loaded field. If you placed a modified InputfieldPageTable in /site/modules/ please remove this and install LimitPageTable v0.0.2: LimitPageTable.zip 1. This is straightforward - in "Table fields to display in admin" just use template.label instead of template, and change the module to match against tpl_label: return $(this).text() == tpl_label; I considered making this the default for the module but I don't like the header given to the table column when this option is set. 2. Not sure what you mean here - the button is disabled in the PageTable field, isn't it?

I think that PW modules should remain in whatever namespace PW is using. In the case of 2.8, that is the root namespace. In the case of 3.0, that is \ProcessWire. Then, include a directory namespace (such as src), and use your namespaces there only. This seems most logical to me...

OMG Reno that looks exactly like what I was asking for. Admit it man, you just slapped that together, just cause you can. Now the question is, how many beers will we have to buy you to get that code?

Looks really great @renobird - I know you say it it is specific to your environment and not meant to be released, but are you rethinking that? The one thing that we discussed in the Tracy thread about this was the ability for the tickets to be initiated from a link on every page so the user doesn't need to specify the page, and also so that the devs can view tickets relevant to the page they are viewing. I'd hate to see us all reinventing the wheel here - how can we move forward?

I haven't really read all of this thread, but just wanted to chime in with a brief overview of a help desk system I built. I can only show you screen shots from the test server — since the real one has sensitive data — but I think you get the idea. Unfortunately it's all pretty specific to our environment here, and was never intended to be released. Ticket List This is pretty small in the test environment. The lighting bolt icons open a modal that shows some "quick look" information for admins. Last comment, ticket history, etc... It's just a way to quickly peek into a ticket without opening it. Ticket View Many of these test tickets are filled with a ton of content, but here's one that shows some of the features. It's conversation based. You can attach specific equipment (we have several equipment databases managed in other PW modules). You can add files/images to any reply. Typical help desk stuff really. Reply options This is at the bottom of the discussion, a lot like it is here in the discussion forum. Agents can reply or create an internal note.

No. Never. Should I? From time to time I dream about some code someone might need and put it inside a module Thanks @LostKobrakai for pointing out the sandbox mode. more about sandbox mode

So I found the reason behind redirects: I'm using the multilanguage version of Processwire, and it adds the language id to URLs (e.g mysite/en/page/) My request URLs didn't have this language string in them (e.g mysite/page/) which caused them to be 301 redirected I was able to find this out by using this plugin, which gives more detailed information about headers than Chrome dev tools (redirects are not bundled into one entry): https://chrome.google.com/webstore/detail/live-http-headers/iaiioopjkcekapmldfgbebdclcnpgnlo Thanks for the help I received