abdus

I was able to include Processwire using use ProcessWire\ProcessWire; // specify installation root $wire = new ProcessWire('../'); To answer your question, I dont think it's required. Here's the relevant bit from the core. // wire/core/Processwire.php /** * Create a new ProcessWire instance * * ~~~~~ * // A. Current directory assumed to be root of installation * $wire = new ProcessWire(); * * // B: Specify a Config object as returned by ProcessWire::buildConfig() * $wire = new ProcessWire($config); * * // C: Specify where installation root is * $wire = new ProcessWire('/server/path/'); * * // D: Specify installation root path and URL * $wire = new ProcessWire('/server/path/', '/url/'); * * // E: Specify installation root path, scheme, hostname, URL * $wire = new ProcessWire('/server/path/', 'https://hostname/url/'); * ~~~~~ * * @param Config|string|null $config May be any of the following: * - A Config object as returned from ProcessWire::buildConfig(). * - A string path to PW installation. * - You may optionally omit this argument if current dir is root of PW installation. * @param string $rootURL URL or scheme+host to installation. * - This is only used if $config is omitted or a path string. * - May also include scheme & hostname, i.e. "http://hostname.com/url" to force use of scheme+host. * - If omitted, it is determined automatically. * @throws WireException if given invalid arguments * */ public function __construct($config = null, $rootURL = '/') { ... }

Hey, I sent a pull request to fix parsing error with message 'unicode entity not defined' when using author field that contains unicode (Turkish) characters. I also added atom namespace and atom:link property under channel to pass W3C validation.

Check out Browser History API (History.pushState()) that helps you change the url using JS and PJAX libraries that do the heavy lifting for you. Here's one (I haven't used) https://github.com/defunkt/jquery-pjax for History API https://developer.mozilla.org/en/docs/Web/API/History

Done! Thanks.

I forgot to update module info file. Fixed it and pushed v1.0.1, module repository should update in a day I guess. Thanks a lot for the heads up!

The issue may be specific to this image. Is it possible for you to link the original?

There's $page->next() and $page->prev() methods available that returns sibling pages matching an optional selector. You can use $next = $page->next("published>$page->published, template=$page->template"); $prev = $page->prev("published<$page->published, template=$page->template"); Then you can echo their urls and build your own simple navigation. See: https://processwire.com/api/ref/page/ https://processwire.com/api/ref/page/next/ https://processwire.com/api/ref/page/prev/

->size(200,0,'upscaling'=>false) Put options into an associative array, also there's quality option as well echo $child->post_image->first()->size(200,0,[ 'upscaling' => false, 'quality' => 95 // defaults to 90 ])->url; See https://processwire.com/api/ref/pageimage/size/ for all other options

ProcessWire Prism JS Syntax Highlighter A module to parse given HTML and syntax-highlight code elements using Prism JS Features Support for 120 languages Very lightweight, core weights 2KB minified gzipped. Customizable. Specify your own CSS, or use one of 8 default themes Hookable. Use hooks to specify your own custom CSS, and JS Plugin support. You can use all available plugins that come with Prism JS. Installation Add module to /site/modules/ and then install. Or go to Modules > Install > Add New and use any of the options provided to to install. Create a text/textarea field or use an existing one then pick Prism Code Highlighter from Details > Text Formatters. Protip: This module parses HTML markup, so it should come after HTML parsers such as Markdown textformatters. Add code elements within the field content with language-xxxx classes. Or pick a default language from configuration page if you are unable to specify the classes. Go to configuration page and select any plugins you want. To use some plugins, extra classes are required. See plugin documentation. Install these recommended modules for the best experience: Parsedown Extra module to render Markdown Extra into HTML. You can also set custom attributes for each element unlike vanilla Markdown. Customization Go to module configuration to specify: Auto inclusion of highlighters for parsed languages Default language for inline code elements or ones without language-xxxx classes. Ability to use minified/non-minified component and parser files Plugin options Theme options Custom JS and CSS for configuration / theming Ability to use hooks to specify custom CSS and JS Hooks Hook into TextformatterPrism::getCustomCss and TextformatterPrism::getCustomJs in your ready.php file and return an (array of) URLs as follows: // specify custom CSS wire()->addHookAfter('TextformatterPrism::getCustomCss', function (HookEvent $event) { $event->return = 'path/to/custom.css'; }); // Specify custom JS wire()->addHookAfter('TextformatterPrism::getCustomJs', function (HookEvent $event) { $event->return = ['path/to/custom.js', 'another/custom.js']; }); Screenshots Links https://github.com/abdusco/pw-prism-code-highlighter http://prismjs.com/ http://modules.processwire.com/modules/textformatter-prism/

Thanks for the response, I'll check out @Macrura's work, and try to improve that instead. It is frustrating to find out you've wasted half a day, but I've learned a lot on module creation, so that's a plus.

Turns out I created this exact module by macrura unknowingly. Should I add it nonetheless?

Processwire SimpleMDE Markdown Editor A module that integrates SimpleMDE Markdown editor to Processwire. Screenshot Features Very simple and elegant design. Shortcuts! Displays raw markdown markup or rendered output. Uses Github Flavored Markdown for displaying rendered HTML. Ability to use monospaced font, syntax highlighting or custom configuration for the editor. Installation Add module to /site/modules/ and then install. Or go to Modules > Install > Add New and use any of the options provided to to install. Install these recommended modules for a frictionless experience: Parsedown Extra module to render Markdown Extra into HTML Image Markup to use image fields in Markdown inputs. Links https://github.com/abdusco/pw-simplemde-editor

Actually, no. I ended up doing that, since it was the least cumbersome way of doing it. Other methods requires going through hoops to modify core behaviour, which I wanted to avoid doing too much in the first place. I created created another field "devTags" and renamed the original to "blogTags" and created a new template for posts under /dev named "work" /blog (template: listing) /tags (template: tags) tag1 (template: tag) tag2 post1 (template: post, field: blogTags) post2 post3 /dev (template: listing) /tags (template: tags) tag1 (template: tag) tag2 work1 (template: work, field: devTags) work2 then without changing the templates, I created a new property hook that redirects $page->tags to correct tags field (blogTags or devTags) depending on the name of the rootParent of the post/work. // return pages referenced with tags field depending on the rootParent wire()->addHookProperty('Page::tags', function (HookEvent $event) { $page = $event->object; $fieldName = $page->rootParent->name . 'Tags'; // check if field actually exists if (!$page->fields->get($fieldName) instanceof Field) { throw new WireException("{$page->template->name} template does not have $fieldName field."); } $event->return = page("$fieldName"); }); I also created another hook that lets me get the pages tagged with a specific tag, for when listing posts/works under the url /blog/tags/tagName // return posts tagged with the current tag page wire()->addHookProperty('Page::tagged', function (HookEvent $event) { $page = $event->object; $fieldName = $page->rootParent->name . 'Tags'; if ($page->template->name === 'tag') { $event->return = pages("$fieldName=$page"); } else throw new WireException('Only pages with tag templates can use tagged property'); }); # EXTRA: A bit of overengineering: change field name when rootParent's name changes // rename tags field depending on its rootParents name wire()->addHookBefore('Pages::renamed', function (HookEvent $event) { $page = $event->arguments(0); // check if page cant have tags template under it if ($page->template->name !== 'listing') return; // check if actually has tags template under it // if(! $page->hasChildren('template=tags')->count) return; $oldFieldName = $page->namePrevious . 'Tags'; $tagsField = fields()->get($oldFieldName); if (!$tagsField instanceof Field) return; /* @var $tagsField Field */ $newFieldName = $page->name . 'Tags'; $tagsField->setName($newFieldName); $tagsField->save(); wire()->message("Renamed $oldFieldName field to $newFieldName", true); }); Thanks a lot for the insight!

Hmm, that method looks interesting, but as you said it's not future-proof. Also, the method utilizes other methods and fields from InputfieldPage class itself, so replacing it won't do any help either.

I tried that as well. I can intercept and hook into InputfieldPage::processInputAddPages events, and change parent id to correct one, but PW ignores the change. // choose correct tags parent depending on the listing under which page the post lives wire()->addHookAfter('InputfieldPage::processInputAddPages', function (HookEvent $event) { // The parent page the field is set up with // $parentId = $event->object->parent_id; // $parent = $event->pages->get("id=$parentId"); // the page that is currently being edited $currentPage = $event->pages->get($event->arguments(0)->id); $rootParent = $currentPage->rootParent; // correct tags page $tagsPage = $event->pages->get("template=tags, has_parent=$rootParent"); $event->object->parent_id = $tagsPage->id; }); // PW ignores the change in parent_id Changing addHookAfter to addHookBefore does not help either.

The custom PHP behaviour was changed recently with v3.0.45, PW no longer allows using custom PHP in frontend, it asks you to use a hook. https://processwire.com/blog/posts/pw-3.0.45/

Exactly. By hooking into InputfieldPage:getSelectablePages method, I'm able to reference correct tag pages depending on the rootParent, however it does not allow me to quickly create tag pages under correct rootParent, as you can only select one parent. When editing a post under different rootParent than the one that Page field is set up with, creating new tag pages gives error "Page $page does not have required parent $parent_id".

Hey, I'm building a website with following page hierarchy home/ /blog (template: listing) /tags (template: tags) tag1 (template: tag) tag2 tag3 post1 (template: post) post2 post3 /development (template: listing) /tags (template: tags) tag1 (template: tag) tag2 post1 (template: post) post2 Ok, so I created a Page field to reference tag pages for categorization of posts in different listings. I set up the field to use InputfieldPageAutocomplete module for quickly referencing and creating any number of tags within a post. However, during the setup, Processwire allows me to pick only one parent. I want to change this behaviour such that when searching for a tag, it should only search under its own listing. Specifically, posts under /development should only be able to reference tags under /development/tags and those under /blog should reference tags under /blog/tags etc. Also, when I create a new tag, it should create under its own tags page. I don't want to use a tags page under the homepage, because I want the URL structure to be /blog/tags/journal or /dev/tags/processwire etc, not /tags/processwire. I know I can use input()->urlSegments to achieve the url structure I want, and I did it like that in the past, but it felt too hacky to change the paths for pages from their own path in page tree. I tried hooking into InputfieldPage:processInputAddPages method to make the field accept the correct tags page, but I couldnt make it work. How can I achieve this?

I sent a PR request on GitHub to fix the warning PHP gives when the field is empty.

I use PHP5.5 on my local dev environment, but 7.0 on production. It's a small sacrifice for the convenience of using step-by-step debugger instead of echo and var_dump(). It sucks that PW doesn't work well, but until it gets fixed, I'll have to settle for v5.5.

Problem originates from the use of __debugInfo() magic method that comes with v5.6. Try using PHP 5.5. Processwire + xDebug doesn't play well with PHP >= v5.6.

I'm having this issue as well. During the development I get logged out whenever Processwire crashes due to some error. Using LastPass's autologin feature helps but it's not a proper solution.

I'm using the latest version 3.0.7 from devns branch, and I solved it by disabling the compilation. As the purpose of the compilation is stated: Enables ProcessWire to update your template file for namespace and apply any installed FileCompiler modules. Recommended unless it causes errors with your template file. I don't need it anyway since I am already using the ProcessWire namespace in template files. However, I tested it once again by enabling compilation, but still the default value returns, not its translation.

Another question: is there a way to completely turn off the compilation of template files?

Found something. When I disable the compilation of template file, it starts working. // correct html output with template file compilation turned off <!doctype html> <html lang="tr">