Leaderboard

And here we go again - general filter for AdminDataTables:

Preview of the new filterbox for modules - the dots in the tabs shows that items are found there:

Hi @Zeka 1. Those dot folders are backup copy of the previous module version. It is safe to delete. 2. Yes, it is safe to ignore those folders.

Hi David, maybe this could help?

Hej, hummmm - I'd add the advice not to let yourself drown in those buzzwords and stuff. Every time I learn something completely new, I run against this wall of all those phrases and things and buzzwords maybe and blah and so many stuff I don't know and try to grasp it all at once but—of course that's not possible. Instead, everything will come together after a while—almost automatically—if you just start to work with processwire (or whatever). As you said, grab the next best "starting at zero" tutorial and—again, ignore the confusion about all the unknown things!—just dig yourself through it. Sometimes you will be stuck - but then sometimes it will also make "click!" ... and the clicks will come more and more often ... And also ask questions here! Without knowing, you will have learnt the difference between a "template" and a "template file" ... I think https://processwire.com/docs/tutorials/hello-worlds/ pwired suggested is very good, because you will start from a simple HTML page which could also live without processwire - but you will integrate processwire into that page step by step. (Or maybe it's rather the other way around - as you see it ...) Whats your general programming / website building experience btw?

So, this is kind of a heads-up: I've just pushed version 1.3.2 of ProcessChangelog to GitHub, and this version includes a bunch of UI changes. Hopefully they make as much sense to you folks as they do for me. To be honest the old look of the module was a bit too ProcessWire 2.0'ish, and I've also been meaning to add clickable action/template links etc. for a while now.

Tom. Very nice gesture from your company! Redactor has been discussed multiple times. I think some of the reasons why it hasn't been implemented are: - unclear license - it is a lot work (link and image modals) - not generally agreed that it is better than ckeditor

I'm using the Eventbrite API to output events but ideally I'd like to create and update pages for each event (so each event on Eventbrite has a page on PW); these should be read-only so only data is taken from EB and not editable on PW. I reckon it'll be fairly easy to create the pages... I guess it's the checking 1) if the page already exists and 2) if any content has changed. This is a job on offer and would like some idea of cost and if it's possible.

COMPOSER ELLIOTT CARTER (December 11, 1908 - November 5, 2012) is internationally recognized as one of the most influential American voices in classical music, and a leading figure of modernism in the 20th and 21st centuries. https://www.elliottcarter.com/ This site was launched some months ago, and was one of the larger projects I completed so far. It took about 4 month to build. (PW 2.7.3) This was the first project I used the wireRenderFile() pattern on, and it consequently allowed me to reuse a lot of output code, as well as do a lot of markup/object caching with wirecache. The site uses DataTables for all of the major listing pages, Works, Discography and Events, allowing users to filter and search with no page reload. This probably has the most advanced caching setup that I've done so far, and one example of how it works is on the discography page: https://www.elliottcarter.com/discography/ That page has to hold all 264 albums (json object which is rendered by dataTables), and each album takes a bit of processing to render (formatting of works, artists etc.). The json for each album's list view is wirecached individually and is generated on visits to the individual album pages, so that they never get generated all at once when visiting the discography page. The complete json object containing all of the albums is also wirecached, then the final page is pro-cached. The album covers are lazy loaded so as to not affect page size or load speed. The selects on the left are also all wirecached as page or regular arrays. This results in a 1.6s page load time and a page size of 1.12 MB. Without the data being wirecached the load time is around 9 seconds to generate the page, probably longer if it had to regenerate all 264 albums, but the album info never changes, so they are permanently cached unless someone edits one. Also should note that since there is so much use of wirecache, @Soma's Clear Cache Admin was pretty much indispensable for managing all of the caches. Other features of the site include extensive use of Schema.org microdata, an events submission system, and a lot of custom stuff in the admin for managing the content, such as automated fetching of album covers from Amazon, converting formbuilder submissions into events, a custom admin dashboard etc.. There are probably 60 modules in use overall, but these in particular saved the day: MenuBuilder AdminCustomFiles AdminPageFieldEditLinks All the Selectize modules URL checker PrevNextTabs WireMailMailgun SetupPageName Changelog AdminCustomPages Twitter Feed Social Share Buttons RSS Enhanced Chosen Select Runtime Markup Batch Child Editor Tracy Debugger As well as all of the pro modules (ProFields, FormBuilder, ListerPro, and ProCache). More info, screen shots etc will be gradually posted here...

Something to consider: if Redactor can be bundled and distributed with open source software, why not use it as a basis for a third party inputfield module instead? InputfieldCKEditor itself started out as a separately distributed module, and considering the way ProcessWire works, this doesn't really need to be part of the core package. While Redactor seems like a decent editor, personally I would be against bundling a closed source application with an unclear license into ProcessWire. Judging from various posts out there, no one is entirely sure how the license works (not even the Craft people), and to me that is a huge red flag.

We also use Statamic CMS on some of our clients sites. Statamic uses Redactor 1 and 2. Statamic v2 initially used Redactor 2 as their WYSIWYG editor but reverted back to Redactor 10 (v1) because of various issues. Having used both CK Editor and Redactor, I would say it is not worth the time nor money/resources. Redactor is problematic, from both developers and end-users PoV

hi ivan, not related to processwire but i think you get the point: http://jsfiddle.net/3gz43tqq/3/ hope that helps

Make sure you're not echoing $home = $pages->get("/"); too, can't think of another reason.

$home = $pages->get("/"); // It returns the ID of the page, 1 because is the homepage $home = $pages->get("/")->url; // It returns the homepage path Edit: Probably not related with the behaviour you are facing. Are you using the "phone" field?

@Nico Smit our last PW project was released when 3.x was not yet stable, so we haven't yet toyed with the latest stable branch of PW. We'll be starting one or two new PW sites in the coming months, but with our current backlog I'm not sure we'll be getting there any time soon! In my spare time I'm building a project for our company on PW which will be starting in the next couple weeks, so I'll have to ascertain how quickly I can resolve those issues. If it's not too much trouble (I think it may come down to refactoring how our classes are instantiated / namespaced) I'll update the boilerplate then, but with our deadlines I may be forced to carry on with 2.x until I do get the time. @Nico Smit if you can open an issue, or even make a pull request it would be much appreciated!

New version is now available at GitHub. Added new option to exclude/include module execution at selected templates/pages + new $sanitizer->emo() method to manually control obfuscation for given string. Please go ahead and try it out!

// "/" is the home page $home = $pages->get("/"); echo $home->phone;

v0.8.5 is up with three new CKEditor plugins and hotkeys to focus the search field (alt+d and double shift). If you have downloaded the module a few hours earlier then please download again from GitHub. One of the CKEditor plugins caused a js error that prevented saving the field in certain circumstances. The good news is that I've found the error and the author has already merged the patch. I've also modified the focus search hotkey from ctrl to shift because it interfered with the save hotkey (ctrl+s).

Sorry if this a bit of a rant. I'm in the last steps of getting our intranet "reborn" on PW, and one still unanswered question is what search backend to use. As with most intranets it holds quite a big number of office and pdf files. I've already tried a few of the major open source search engines like ElasticSearch, Solr, Sphinx and OpenSearchServer, and I found all of them lacking in two regards - for one, the documentation is all over the place so you never know if the piece you're reading even applies to the version you're using, and the implementations of their APIs are just horribly awkward and extremely picky in regards to the slightest deviations from their "standard" (which isn't really concisely documented) syntax. None of them comes with a basic permission system, which is an absolute must have. I can probably work around that with facets or the like, but still... you'd think everybody all over the world but me only indexes public webpages. Design decisions like using JSON objects that have multiple identically named properties make me doubt the sanity of those maintaining the software. Looking at all these points, I'm now also considering rolling my own on top of an InnoDB fulltext index, just re-using the text extractors I've already running in the old system (up to now only feeding the extracted plaintext into a MySQL table and doing literal searches), adding a fulltext index, setting up a lean API module for the few search variants I need and be done with it. That, of course, still leaves the topic of extracting relevant snippets open - should I write my own UDF for that, or are there (functional and maintained) third party extensions available to do just that? A question that warrants some more digging for an educated decision. I'm still a bit torn, but there's also the time factor to consider. If any of you has experiences with searches (especially with implementing visibility of search content using a group-based permission concept) and could throw in a few pointers or experiences, I'd be glad.

It should be working with the namespaced Version CroppableImage3. If it doesn't, you may strip out the namespace ProcessWire; at the top of all files, then install it with $config->debug = true; and look out for any failing function or class instance call that is prefixed with a backslash (\), if there are any of those errors or warnings, go into that file and line and remove the backslash (\). After that it will work. Other way would be to notify Ryan, that this module doesn't work with automaticly switching from v3.0 to v2.8 through the FileCompiler. Maybe he is willing to look at it and can justify the FileCompiler to identify and handle some special cases there too.

niiiiiice, glad it worked right away! You're very welcome! also let's worship Ryan and contributors, for the brilliant architecture of processwire making it possible! ^~^

You're correct, that there's no function context, but a return statement does also stop the execution of code in files loaded by require/include statements. Most often a $this->halt() without return doesn't make much sense.

You can find a to z beginners tutorials on many places, just google them: https://processwire.com/docs/tutorials/hello-worlds/ https://processwire.com/docs/tutorials/simple-website-tutorials/ And then there is youtube with complete beginners tutorials, like this one starting with a blank profile https://www.youtube.com/watch?v=IHqnLQy9R1A

Shouldn't return $this->halt(); be used instead of exit(); ?

Unrelated to what you're experiencing, but when I upgrade PW on my WAMP setup AND if I have a project open in Sublime Text containing that PW instance, the upgrade will "fail" at the last step whereby it renames the directories. Not a bug, but something to be careful for. It's easy to fix however if that occurs... just rename the 'wire-3.x.xx' directory to 'wire'.

Hej, I think thats no problem. When you have the link between synonyms and entries like I described, it is easy to retrieve the tags from the entry when you query a synonym: <?php # # "linked_entry" is the page field on the synonym holding the # reference to the entry. # synonyms have no tags field. # // get the tags of synonyms $a_synonym = $pages->get("parent=synonyms, name=airplane"); $synonyms_tags_via_its_linked_entry = $a_synonym->linked_entry->tags; // edit: in one line: $synonyms_tags_via_its_linked_entry = $pages->get("parent=synonyms, name=airplane")->linked_entry->tags; // find synonyms with tags $those_synonyms = $pages->find("parent=synonym, linked_entry.tags=some_tag|another_tag"); You just need to tag your entries and through the link in the synonym its very easy to handle anything tag related. But the syncing you describe would still be possible - though I don't think you need that if the tags of the synonym and the entry will always be the same. Regarding hooks: Have a close look at https://processwire.com/api/hooks/ and this when you got the idea: https://processwire.com/api/hooks/captain-hook/ and also search the forum for more examples! This is a rough sketch of a hook that might sit in the init.php / ready.php file. It may work out of the box, but I am still in the trial and error phase when it comes to hooks and haven't teste this one but it should work more or less somehow like this: <?php # keep synonyms linked_entry in snyc with entries synonyms wire()->addHookAfter('Pages::saved', function($event) { $page = $event->arguments(0); // what page was the hook called on? $template = $page->template; // what template has that page // see if the saved page is an entry because this hook is called on every page save if($template == "entry") { /* $related_synonym_pages = $pages->find("parent=synonyms, name={$page->synonyms}"); foreach($related_synonym_pages as $syn) { $syn->setAndSave("linked_entry", $page); } */ // haha, this happens to me all the time, the following should be simplier =) foreach($page->synonyms as $syn) { // get the set synonyms directly from the page $syn->setAndSave("linked_entry", $page); // set this page to that synonym } } }); So, this is the hook for: Edit synonyms on entry page, save it → hook updates the related synonyms which are set on the entry page enjoy

This week we've got a new dev branch version with several updates which we'll merge to master soon. This post also includes a useful recipe on how to log all outgoing emails sent from your site. https://processwire.com/blog/posts/processwire-3.0.38-core-updates/

@szabesz - I had a play around to see how you could use custom PHP replacements in the description field. My first thought was create a module where you define tag/code pairs in the module config, then look for and replace those in descriptions. This works, but requires the use of eval() and conventional wisdom is that eval() is evil. So my next thought was Hanna Code, and this seems to work great. In ready.php (or create an autoload module): $this->addHookBefore('Inputfield::render', function($event) { if(!$this->wire('modules')->isInstalled('TextformatterHannaCode')) return; if(!($this->wire('process') && $this->wire('process')->className() == 'ProcessPageEdit')) return; $inputfield = $event->object; $description = $inputfield->description; if($description == '') return; $this->wire('modules')->TextformatterHannaCode->formatValue(new Page(), new Field(), $description); $inputfield->description = $description; }); Then set up the Hanna codes you want to use in description fields. If you want to get the page object for the page being edited then add this at the top of your Hanna code... if($process && $process->className() == 'ProcessPageEdit') { $p = $process->getPage(); } else { return "[Hanna code '$hanna->name' is not valid for this field]"; } return $p->url; // an example to return the URL to the page without scheme and hostname ...then access the page object as $p

I thought I should post my implementation based on Bernhard's code. It tries to work out the length of the first tag and modifies the ->asXML parameters accordingly. The Import Code is as follows : class ImportFromXML { private $file; public function __construct($file) { $this->file = $file; } public function Execute() { $import = true; $xmlFile = $this->file; if ($import) { if (!file_exists($xmlFile)) exit($xmlFile . ' failed to open'); $items = simplexml_load_file($xmlFile); foreach ($items as $xml) { $p = new \Processwire\Page(); //$p = new \Page(); $p->of(false); $p->template = wire(templates)->get("id=" . $xml->template); $p->parent = wire(pages)->get("id=" . $xml->parent); $p->title = $xml->title; //Struggle to call Sanitizer $p->name = wire(sanitizer)->pageNameUTF8($xml->title, true); $p->name = $xml->title; //while ($xmls->find('parent=' . $p->parent . ',name=' . $p->name)->count() > 0) $p->name .= '-1'; //$p->content = $this->PopulateContent($xml->content); $p->content = $this->PopulateMarkup($xml->content); //$p->content_intro = $this->PopulateIntro($xml->content_intro); $p->content_intro = $this->PopulateMarkup($xml->content_intro); $p->author = $xml->author; $p->content_path = $xml->content_path; $p->seo_title = $xml->seo_title; $p->seo_keywords = $xml->seo_keywords; $p->seo_description = $xml->seo_description; $p->seo_image = $xml->seo_image; $p->seo_custom = $xml->seo_custom; $p->image = $xml->seo_custom; $p->image_alt = $xml->image_alt; $p->keywords = $xml->keywords; $p->title_nav = $xml->title_nav; $p->seo_section_title = $xml->seo_section_title; //$p->save(); // try creating PageArray first ???? //$cats = new \PageArray(); $cats = new \Processwire\PageArray(); foreach ($xml->category->id as $id) { //$cat = wire(pages)->get("name='" . $catname . "', parent='/Categories/'"); $pageid = (string) $id; $cat = wire(pages)->get($pageid); if (!IsNullPage($cat)) $cats->add($cat); //$p->categories->add($cat);- } $p->category->import($cats); $p->save(); echo 'new page <a href="' . $p->editUrl . '" target="_blank">' . $p->path . '</a><br>'; } //die(); } } private function PopulateMarkup($node) { $xml = $node->asXML(); //Check for tags if($xml != strip_tags($xml)) { //$startTag = strpos($node,"<"); $endTag = strpos($xml,">"); if ($endTag > 0) return substr($xml, $endTag+1, -1*($endTag+2)); } return $node; } } And the Export : class ExportToXML { private $pages ; public function __construct($pages) { $this->pages=$pages; } public function Execute() { $import = true; if($import) { echo "<?xml version='1.0' ?>"; echo '<pages>'; //$parent = $pages->get('/blog'); $results = $this->pages; //$results = $pages->find('id=3198'); // ohne pic //$results = $pages->find('id=3204'); // mit pic foreach($results as $p): $p->of(false); ?> <page> <name><?= $p->name ?></name> <title><?= $p->title ?></title> <template><?= $p->template->id ?></template> <parent><?= $p->parent ?></parent> <category><?php foreach($p->category as $category) { echo '<id>' . $category->id . '</id>'; } ?></category> <content><?= $p->content ?></content> <content_intro><?= $p->content_intro ?></content_intro> <author><?= $p->author ?></author> <content_path><?= $p->content_path ?></content_path> <seo_title><?= $p->seo_title ?></seo_title> <seo_keywords><?= $p->seo_keywords ?></seo_keywords> <seo_description><?= $p->seo_description ?></seo_description> <seo_image><?= $p->seo_image ?></seo_image> <seo_custom><?= $p->seo_custom ?></seo_custom> <seo_canonical><?= $p->seo_canonical ?></seo_canonical> <image><?= $p->image ?></image> <image_alt><?= $p->image_alt ?></image_alt> <keywords><?= $p->keywords ?></keywords> <title_nav><?= $p->title_nav ?></title_nav> <seo_section_title><?= $p->seo_section_title ?></seo_section_title> </page> <?php endforeach; echo '</pages>'; //die(); /** * <date><?= $p->created ?></date> <featured>1</featured> */ } } } In particular, I had a field that was a PageArray linking to other Pages. <category><?php foreach($p->category as $category) { echo '<id>' . $category->id . '</id>'; } ?></category> Hope it helps some one out!

It's not so much migrate or migration but just building upon what the processwire API provides. I really do appreciate the "freedom" the API provides, but I also sometimes wished there was some structure or guidance to follow (i.e. a Framework). You'll have to excuse me coming from a .NET background and still struggling with a lot of PHP's idiosyncrasies and gotchas. I'm not saying a Framework is useful for every scenarios, but for some scenarios it would be much quicker to get a site going if we could leverage reusable, tested components ala a Framework. I'm sure there are plenty here that have built their own framework(s) over the years. Would be nice to see an official or a collaborated effort.

i think what COULD make sense is some kind of helper module that makes it easy to handle some more advanced features (sometimes necessities) like deviding the import in chunks or providing some helper functions like handling pagename collisions, importing images and so on. but i don't know if there are better solutions already providing such things like using lister pro or batch child editor, import csv and so on. for me it was just the quickest solution to code it on my own. i had only 168 pages in the blog and 165 persons to import and that went without even increasing execution time

The advantage of having it in a separate file is that you are separating your concerns. Logic is kept with logic, markup is dedicated to displaying and layout of the data. This makes it easy to understand where things are, how they got to be there, and where to add what as you extend a site. Have a read through just the views in the boilerplate - there is no repetition, everything is well organised and brief, and it is easy to understand where markup is being obtained. Many functions will be specific to just one template, but other logic is likely to be shared across a number of templates. Abstracting logic away from markup ensures that you can quickly find where to add logic, or where logic is being defined. You can see how we have achieved this with the controllers/traits files - SEO, Search, Opengraph, etc. A nice result of this methodology is that your files are often shorter, and easier to manage. In the Ruby realm it's considered good practise to keep functions down to approximately 5 lines, so that they are brief, and achieve only one goal. Keeping files to an approximate maximum length of 100 lines is another good practise - try reading through WordPress core files; it won't be long before you find a monster 1000+ line file (possibly even a single function of that length). That's insane, a nightmare to navigate and manage, and is plain horrible for devs when debugging WordPress' innumerable quirks. When your files and functions start exceeding these numbers, there's often room to neaten things up, make things more concise, and abstract functionality elsewhere. It helps you, helps future devs, and makes unicorns poop rainbows! You can, of course, write all of your logic into the template, but then may you lose reusability of the code, and will undoubtedly lose brevity, or have to add logic in places which may not make sense. MVC removes this issue entirely - you always know what goes where. ProcessWire allows you to use _init.php and other mechanisms to handle this, but that can quickly become unwieldy, so abstracting concepts to separate files can then become beneficial. I'm sure the boilerplate can also be achieved using modules, but it made sense for us to keep the controllers right with the views (as in Rails), since controllers are created as we add templates in the admin. Perhaps in the future it would be beneficial to move the logic out to modules, but we'll only look at that should we see a benefit over how we're doing it right now. It's awesome that we have the flexibility to make such decisions with ProcessWire. Another cool thing is that when you don't want to use the MVC approach, such as when you want a template to redirect - then you don't use MVC! Point the template directly to its file, and put the redirect straight in there, bypassing all the boilerplate logic. You get the best of both worlds.