Leaderboard

The latest core dev branch coming soon to the master branch, plus several Pro module updates and more. https://processwire.com/blog/posts/processwire-3.0.59-module-updates-and-more/

Well now I am embarrassed. So sorry. It turns out upgrading to the latest graphql library broke some stuff. For some reason I did not check the queries without the selectors. I made some fixes. This should solve your problem. Please get the latest version and try again.

As fas as I know, currently there is no way for a module developer to include a changelog in a way that enables us to check out the changes in the admin before upgrading.

Could you please describe where the problem was and how you resolved it, in case people have similar problems in the future? Thanks.

This sounds to me like it's a permissions/access issue - so not so much about which browser but about the fact that you were probably logged in as superuser when you were first viewing the website, but you're a 'guest' when viewing in those other circumstances. Have you done anything out-of-the-ordinary around access, e.g. removed guest view permission for a template or a field? It looks like you have a single page frontend where you pull sections of content from child pages. Did you maybe do something to try and prevent direct access to those child pages? Just trying to work out why guest access would be limited somehow.

By overriding $config->paths and $config->urls, I got it to work. Both sites use different directories for uploads unaware of each other. I couldn't override $config->site->assets, which would have been a much better option, anyone know how? <?php $config->dbHost = 'localhost'; $config->dbPort = '3306'; $config->httpHosts = array('pw.dev', 'pw2.dev'); if($_SERVER['HTTP_HOST'] == 'pw.dev') { $config->dbName = 'pw'; $config->dbUser = 'pw'; $config->dbPass = 'password'; $config->paths->files = $config->paths->site . '/assets/files-first/'; $config->urls->files = $config->urls->site . '/assets/files-first/'; } else /*if ($_SERVER['HTTP_HOST'] == 'pw2.dev')*/ { // remember to default to some site if HTTP_HOST is not set! $config->dbName = 'pw_dev'; $config->dbUser = 'pw_dev'; $config->dbPass = 'password'; $config->paths->files = $config->paths->site . '/assets/files-second/'; $config->urls->files = $config->urls->site . '/assets/files-second/'; } Checking path is quite good, I'll probably implement some setup like this to set up a staging environment. Right now I'm just using reverse SSH tunnel to redirect localhost to web. One thing however, since both sites use the same templates, paths wouldn't be different, but you can create a symlink to solve that.

It turns out it's hidden under ProcessPageEdit module configuration. Then you can follow the navigation to add bookmarks

@BillH, PW now takes care of link abstraction inside CKEditor fields if the "Link abstraction" setting is checked for the field (which it is by default). There is also the Page Path History module which will take care of redirects when a page path changes (this works for all pages, not just links inside a CKEditor field).

Since I'm doing a lot of detailed logging in our internal PW-based systems, that has become a bit of a bottleneck under heavy load and I was missing a centralized view with the growing number of separate PW instances. So I dug into the core a bit, namely WireLog.php and FileLog.php as well as ProcessWire.php. I managed to whip up my own WireLogDatabase and DbLog classes mimicking the behaviour of the regular logging classes, but not without a little bit of tweaking to the ProcessWire class itself to replace the regular logger. Now I'm logging to a MySQL server instead of plain files and ProcessLogger works smoothly with it without tweaking. I thought it would be shame to keep this all to myself, but a release-worthy version would need or could benefit from: a bit of polishing in regards to error handling and proper treatment of conflicting concurrent operations without too much lock overhead (drop table vs. insert especially) more source code documentation a little more abstraction so all csv operations are deprecated in favor of database columns where avaible last but not least, an approved way to configure the substitute logger and load it early on, which means touching the core ProcessWire class Before I invest too much into that, I'd love to hear all thoughts on this, especially if you think such a module may fit your requirements, and I would be especially happy to hear from @ryan - could you see such a mechanism in the core?

Hi, I have created a site profile that shows how to integrate ProcessWire 3.0 with Vue 2.0. See repository here. How this site profile works This ProcessWire site profile is loosely based on the REST API tutorial by @gebeer. Here are the most important steps to reproduce it: Admin settings Create an api template with default settings and just the title field assigned to it. Refer to @gebeer tutorial for further details Create a pages and nav templates with just the title field, for both template tick “Allow URL Segments” in the “URLs” tab (see attachment) Create a home template, this is going to be the single php file that will load your Vue SPA. Assign this template to the root of your website Any other template you create should have the “Alternate Template Filename” field in the “Files” tab set as home (see attachment), in this way if a user enter the website from any url that is not the root, ProcessWire will always redirect to the home template, Vue router will handle the url and call the right data through the REST API Under the root, create an api page and assign the api template to it (you can set “hidden” to this page so doesn't show up in the menu) Under the api page, create the pages nav and pages (see attachment), and assign the templates nav and pages to them. Now you have the www.sitename.com/api/pages and www.sitename.com/api/nav urls that you can use to fetch the JSON data PHP template setup In the templates folder, create home.php file and leave it empty, the HTML will be generated by webpack Now create pages.php and nav.php files. On these files is where we return the JSON data, based on the right url segment. Again, refer to @gebeer tutorial for further details on this matter. Note that I wrote a PageFields class that I use on these templates to fetch ProcessWire fields. The fields that are supported are text, textarea, repeater, img. Other fields may work but I haven't tested them. See the REST API setup for further details about how to use the PageFields class REST API setup You can decide what fields are included and what fields are excluded by passing a configuration array to the PageFields class. You can find here a list of the available configuration settings. See examples below. Show only selected core fields: $pageFields = new PageFields($p, [ 'fld_core_included' => ['url', 'httpUrl', 'template'] ]); Show no global fields, and only selected custom fields: $pageFields = new PageFields($p, [ 'fld_core_included' => [], 'fld_include_all' => false, 'fld_included' => ['title', 'gallery'], ]); On a gallery image field, hide breakpoint listing and show only httpUrl field: $pageFields = new PageFields($p, [ 'img_fld_overrides' => [ 'gallery' => [ 'fields' => ['httpUrl'], 'bp_list' => false ] ], ]); Webpack setup The most important file of all Webpack setup is config/index.js. On line 33 you need to provide your domain name so that Webpack can proxy the ProcessWire REST API to the Webpack dev server. Without this you wouldn't be able to take advandage of the Webpack hot module replacement feature which allows you to reload a vue module without refreshing the page, it also allows you to keep the state of the app. Notes My REST API may have bugs, this is just an example of an integration with ProcessWire, I suggest you either build your own REST API or use the awesome GraphQL module by @Nurguly Ashyrov. Todo Replace REST API with the GraphQL module. This requires vue-apollo, the Apollo/GraphQL integration with Vue, and vue-supply for integration with Vuex.

This morning I pushed a module to github which extends the page api with moving and sorting capability. https://github.com/kixe/PageMove * CALLABLE (static & instance) * PageMove::execute($page, $parent = null, $newIndex = 0, $selector = 'all'); * $modules->get('PageMove')->execute($page, $parent = null, $newIndex = 0, $selector = 'all'); * * EXTENDED PAGE API * @method $page->move($parent, $newIndex = null, $selector = 'all') * @method $page->setIndex($newIndex, $selector = 'all') // set absolute index include=all * @method $page->getIndex($selector = '') // same as $page->index without argument @see getSelector() * * @method $page->moveFirst($parent = null) * @method $page->moveLast($parent = null) * @method $page->moveForward($steps = 1, $selector = 'all') * @method $page->moveBackwards($steps = 1, $selector = 'all') * * @property $page->moveFirst // same parent * @property $page->moveLast * @property $page->moveForward * @property $page->moveBackwards * * EXTENDED PAGES API * @method $pages->move($page, $parent = null, $newIndex = 0, $selector = 'all') * @method $pages->resortChildren($page, $selectorValue) * // same like core function $pages->sort($page, true); with capibility to change the sort condition Have a nice weekend.

A difference perspective as someone who would love to be able to sell PW based websites to clients in the UK, where PW is an advantage not a reason to need their trust . 1) the PW website looks dated and does not highlight what makes PW better (or different) to the myriad of other similar placed CMSs. Drupal got this right in my opinion. They went for a well publicised redesign some years ago. It looked good and worked well (though i don't think the switch to twig templates in D8 is a good idea). 2) growth surely only matters in comparison to others in a similar space and the top 3. Those will less growth will disappear regardless. I think the success of PW will be a clear message showing why it's a better choice than WP, and why it's a more suitable choice than others. Right now there are far too many CMSs in a similar space (business / news / blog websites). What a developer wants does not count for that much as WP has proven. A search for a suitable CMS with any number of criteria for popular website types shows the issue. Each link almost a different list, the only consistent ones being the 3 (Joomla, Drupal, WP). And then there's the static site generators (which are now getting online content management options). So I would love to see PW have an amazing first impression and be presented in a way as something users might choose (which was the magic WP found) rather than only developers. For example, I think Concrete5 see the marketing importance of this and clearly make an effort to attract non-tech people as well. Another example is Grav. Straight away the message is 'no database' and 'faster websites'. Very clear. Here's an article that is about the best I've seen to encourage people towards PW: https://www.cmscritic.com/processwire-vs-wordpress. A lot more of that kind of thing is needed though. PW needs that kind of strong message clearly visible that gives it its space, which not only attracts developers but can be clearly seen by users or the developer's potential client. If it was my project (I know, if I care so much why don't I start one?), then I'd make the following priorities: Update website with a focus on users and potential clients (developers won't care so much) Encourage blog posting that gives fair comparisons, reviews and tutorials for PW Highlight a clear USP to PW that can be the main message on the website and the one for all of us too share Use that USP to define the roadmaps for future development (confidence is what space a project will be matters also) That's my 2 cents.

Back when PW 2.6.17 was released the blog post that week described several types of bookmarks: https://processwire.com/blog/posts/processwire-2.6.17-expands-admin-navigation-with-bookmarks/ In recent versions of PW3 I can't find where Page Tree bookmarks and Page Edit bookmarks may be defined or accessed. Have these two bookmark features been removed?

That was exactely it!! Thank you so much. Problem solved!

Are you doing anything unusual with the way you are loading these pages? It looks like it's trying to load as an image? Have you done some with headers/content type?

In the source code of that page there are lots of entries like this one: <b>Notice</b>: Trying to get property of non-object in <b>/home/rolspace/public_html/hd/praxiszurvorstadt/site/templates/team.php</b> on line <b>13</b><br /> Can you show us the code for that line?

Anything in the logs?

Do you have $config->debug = true; in /site/config.php and/or TracyDebugger installed in order to help you? What about using data-fancybox='images-single' instead of data-fancybox="images-single"? galerie is a simple image field, isn't it? Isn't the img tag missing? Shouldn't it be something more or less like: <?php foreach($page->galerie as $image) { echo "<a href='{$image->url}' title='{$image->description}' data-fancybox='images-single'>"; echo "<img src='{$thumbnail->url}' alt='{$image->description}' title='{$image->description}' />"; echo "</a>"; } ?> But you could also use $thumbnail->description. I guess you have defined $thumbnail... (NB: not sure the {} are needed in this case as there is only one -> used.)

Problem solved. After mailing the provider, everything mysteriously started to work as it should. I fear, I don’t really understand what exactly caused the problems – some weird combination of »properties« and »permissions«, his explanations were not to detailed. So thanks again Horst and Robin for your help. Ralf

Yeah, valid point I just did not follow the thread properly and only spotted the usage of the variable which I also used to use to tell apart my local machine from the server but recently switched to checking the path instead.

Note that "there are times" when $_SERVER['HTTP_HOST'] and similar are undefined, eg. when running PW from CLI (bootstrapping), because of this, I normally use something like this: if(strstr(getcwd(),'/full/path/to/dev')) { // DEV settings } else if(strstr(getcwd(),'/full/path/to/stage')) { // STAGE settings } else { // PRODUCTION settings } [credit]

I tried it, it works just fine. Here's how you do it Create a new database for the other site(s). Add new database user and set correct permissions & privileges. I duplicated mine by dumping into .sql file, changing its name then reimporting in Adminer panel Go to config.php, update $config->httpHosts to include other domains, then add new database info like so: $config->dbHost = 'localhost'; $config->dbPort = '3306'; $config->httpHosts = array('pw.dev', 'pw2.dev'); if($_SERVER['HTTP_HOST'] == 'pw.dev') { $config->dbName = 'pw'; $config->dbUser = 'pw'; $config->dbPass = 'password'; } else if ($_SERVER['HTTP_HOST'] == 'pw2.dev') { $config->dbName = 'pw_dev'; $config->dbUser = 'pw_dev'; $config->dbPass = 'password'; } Update your HTTP server configuration. I use Caddy Server, which makes these changes trivial. # old pw.dev:80 { root /www/pw/ # other configs } # add new host pw.dev:80, pw2.dev:80 { root /www/pw/ # other configs } # both hosts share the same root! Reload HTTP server (Apache, nginx, Caddy etc) and enjoy! Here it is in action: 2017-04-07_11-56-11.mp4 (1MB video, 00:24 sec)

Welcome @shivrajsa, The simplest way would be for the template files in each /site/templates/ directory to consist only of include() statements, which draw from a central templates directory at /templates/. Ryan suggests something like this here: Or, as also mentioned in that thread, you could consider using symlinks.

You should be able to point to different databases in your config.php depending on hostname. Something like this _should_ work, but I haven't tried it: <?php // config.php if($_SERVER['HTTP_HOST'] == 'firstsite.com') { $config->dbHost = 'localhost'; $config->dbName = 'db_for_first_site'; $config->dbUser = 'user'; $config->dbPass = 'password'; } else if ($_SERVER['HTTP_HOST'] == 'secondsite.com') { $config->dbHost = 'localhost'; $config->dbName = 'db_for_second_site'; $config->dbUser = 'anotheruser'; $config->dbPass = 'password'; }

Your permission issues may be affecting all PW files. This error... Compile Error: require_once(): Failed opening required '~/site/modules/TextformatterTextile/src/Parser.php' (include_path='~/wire/modules/Markup/MarkupHTMLPurifier/htmlpurifier/standalone:.:/usr/share/php:..') (line 39 of ~/site/modules/TextformatterTextile/TextformatterTextileField.module) ...relates to a file outside /site/assets/. So when you are testing the change of owner you should do this for all PW files.

@LMD, thanks for the report. Please update to v.0.04 where this issue should be fixed.

I've been doing something very similar -- might I suggest a small change to the page selector to eliminate the need to check for the current page in your foreach loop? // Find the pages that use the specified tag -- and ensure the current page is excluded $articles = $pages->find("template=basic-page, id!={$page->id}, tags.title=$tag, limit=8"); This way, you always get 8 results (if there are that many, of course), whereas excluding page from the loop would leave you with 7 pages.

This module is just what I was looking for! I'm using it to create links to a file download page, instead of to the file itself, with the 'dynamic options' method. However, although it works perfectly, I'm getting a strange error in the Hanna dialogue modal window (see screenshot): I have tried deleting the file compiler cache, but it did not resolve the issue. Set-up Info: Hanna Code: ver. 0.2.0 HannaCode Dialogue: ver. 0.0.3 ProcessWire: ver. 3.0.58 PHP: ver. 5.6.21

You definetly have to check the user rights. If you prviously used apache module, and afterwards changed to cgi mode, I bet that this are different users on the server. Common usage on shared hosts is, that php as apache module is a user something like wwwrun. As cgi version, mostly it is identical with your own ftp user. So, after you switched to cgi, all messages that say you don't have the access rights to the assets directory totally make sence!

You can also do $f = new Field(); $f->setArray([ 'name' => 'field_label', 'type' => wire('modules')->get('FieldtypeWhatever'), 'tags' => 'tag1 tag2', 'label' => 'Field Label', 'columnWidth' => 50, ] );

in another thread I had posted some useful links to this too: https://processwire.com/talk/topic/15886-different-styles-for-results-of-an-array-page-grid/#comment-141785

I am glad that this project is helping ProcessWire getting more devs on board :). I just want to say that I wouldn't have been able to finish ProcessVue if it wasn't for the amazing ProcessWire community. I believe that the community truly is the biggest selling point for new users (like me). Before trying ProcessWire I used OctoberCMS for a while but when I was stuck I got 0 support from the forums, so...althought the CMS is based on the amazing Laravel framework, I just left! I think that ProcessWire is extremely powerful and flexible and with time will become the tool of choice for frontend developers, the new GraphQL module will also help on this direction. Droves of frontend developers are looking for a CMS like this, they just don't know it exists! The usual keywords they use when looking for a SPAs CMS is "Decoupled CMS" or "Headless CMS", and I believe that that's exactly what ProcessWire is for! Some frontend developers prefer to use NodeJS, but the learning curve is huge if you need it for a non trivial project, and the worst thing of all is that after two weeks ANY js tool you may have used is outdated. See for example how Angular has been replaced with React or Vue, and Gulp with Webpack. That doesn't mean that I am against improvements in this regard, I just feel that it's just too much for us poor frontend devs to cope with! ProcessWire is stable, easy to use and won't change API every week. BTW, after that I migrate ProcessVue to GraphQL I am also planning to add Auth0 login integration with JWT, as I think that login/signup is a common feature in SPAs. I am sure I'll have to annoy @Nurguly Ashyrov and the rest of ProcessWire community for getting it in sync with ProcessWire users, but the result should be quite useful

First, some background to lit a light. There are some functions in PHP that may produce unexpected results in special situations. This functions are used by PW core files and in user contributed modules. Some users may have problems with file upload (pdf, zip, image, whatever) if filename has non-ascii character at the first place. For example, if user upload a file named "år.jpg" (year in Swedish language), it is expected that PW would transliterate (transform) the filename to "ar.jpg", but because of the bug in basename() PHP function, the filename would become just "r.jpg". Nevertheless the file would upload successfully. But if the filename is "привет.jpg" (Hi in Russian language) the upload would fail. There are two ways how to handle this: Write and use custom functions instead of builtin functions Let end user fix that with proper locale Option 1. is used in some CMS/CMF (like Drupal), PW (Ryan) opted for option 2. After successful login PW perform a test and warning is issued in case of test failure. It is now your responsibility to set proper system locale. The locale is a model and definition of a native-language environment. A locale defines its code sets, date and time formatting conventions, string conversions, monetary conventions, decimal formatting conventions, and collation (sort) order. Those "problematic" builtin PHP functions are locale aware, that means they work as expected, if locale is configured appropriately. Locale can be set by the underlying operating system or in PHP. Because on shared hosting you don't usually have root access to the OS, the only option to set the locale is by using the builtin setlocale() PHP function. But, before you can use/set the locale, it must first be installed on the OS. On most unix systems at least some basic locales are already there, they are just not used. To check what locale are you currently using and what locales are available for you to use, create the file testlocale.php at the root of your website with the following content: <?php echo "<pre>Current locale:\n" var_dump(setlocale(LC_ALL, '0')); echo "\n\nAvailable locales:\n"; echo exec('locale -a'); Then point your browser to http://yourwebsite/testlocale.php If your current locale is "C" (and you are on unix), then you will probably get warning after login to the PW admin. What you want to do is change the locale to something that has "UTF-8" or "utf8" in the name of the available locales. In your case you would be looking for something like "sv_SE.UTF-8" or "sv_SE.utf8". Now, there is a chance that Swedish locale is not installed. You can ask your hosting provider to install it for you or use some other UTF-8 locale. On most unix systems I have seen, at least "en_US.UTF-8" or "en_US.utf8" is installed. If even that English locale is not available, then look for "C.UTF-8" or "C.utf8". And this is what you have to use as parameter in the setlocale() call: setlocale(LC_ALL, "sv_SE.utf8"); You could actually "stack up" multiple locales and one will eventually work: setlocale(LC_ALL, "sv_SE.utf8", "sv_SE.UTF-8", "en_US.UTF-8", "en_US.utf8", "C.UTF-8", "C.utf8"); Now, regarding where to put that setlocale() call. If you are not using PW multi language capabilities (you don't have Languge Support module installed), then you place setlocale to /site/config.php. That's it. If Language Support module is installed (PW checks for that), you have two options: Translate the string "C" in LanguageSupport.module for each installed language Put setlocale() call in /site/init.php My preferred method is option 1 and this is what PW (Ryan) recommends. See https://processwire.com/api/multi-language-support/code-i18n/ for more info on translating files. Option 1 allows you to set different locale for each of the installed language, while option 2 allows setting of one locale for all languages. PW will also provide links for the files that needs to be translated in the warning message. Ryan just pushed an update that makes it use the locale setting on the frontend when using LanguageSupportPageNames module (until now just language was changed, but not locale). Also setLocale() and getLocale() methods are added to the $languages API var.

Jump jumping in to support this idea. I can't like it twice

I thought of a concept and it doesn't have to be as complex infact here's my proposition There should be a changelog.md and also another changelog.json which contains each version and the text serving as the changes, however this might hard to implement as it means enforcing everyone to do this, another better alternative could be a changelog.md with a specific format to follow, so that a Parser can be read to extract the needed information, it is vital a changelog is seen before uploading to inform user about what has changed and what to expect.

I would also love to see this - I think it would be great if we could define it in a Github repo changelog.md file and have the automatically imported into the text in the modules directory, and perhaps even displayed in the module info within a PW install. Perhaps it would even be nice to have a way to add a flag about breaking changes that would show up in the ProcessWire Upgrades module so you are warned before upgrading. @ryan - any thoughts on this? I'd be happy to work on it - obviously I could do the PW side of it from the repo, but would need access to the php files for the modules directory to make that side of things work.

https://processwire.com/blog/posts/processwire-3.0.14-updates-file-compiler-fields-and-more/#file-compiler-updates https://processwire.com/blog/posts/composer-google-calendars-and-processwire/#processwire-and-composer https://processwire.com/blog/posts/happy-new-year-heres-a-roadmap-for-processwire-in-2016/ "Composer support. While we already have partial composer support in the current devns branch, we still have more work to do in this area before we start documenting and highlighting it." https://processwire.com/blog/posts/multi-instance-pw3/ "PW3 isn't yet up on Packagist, but will be after it's in master release." Hope this helps.

I've been using autossh on a CentOS 7 server for a year. autossh has been in the repositories for fedora/centos for many years and is definitely not forgotten. Just the other day there were two threads about autossh at the linuxquestions.org forums I'd pick another name to prevent name conflicts.

Greets, I know, this thread is quite old but I wanted to throw in some thought, even if they're nonsense My "problem" is user generated content. I have comments, even only a few for now and statistics. I have them in seperate pages, and if a page doesn't have one yet it get's created. So while I'm working offline there could be new pages online. And sometimes while I'm testing something offline, I'm creating and deleting pages, id's are incrementing. This means I'm not able to use $pages->get(1824) any more or just import/export my db. What if the id's would have a prefix? So for example you could define an id prefix for some automated page creation or user content like comments for example $new = new Page(); $new->template = "comment"; $new->idPrefix = 2; So the 2 wouldn't increment. I'm not good with mySQL, but I guess it sounds easier than it is right? Then the id is not a normal integer incrementing as usual and having a different field for the prefix is probably nonsense, too?! But maybe it inspires someone somehow By the way, I don't know how long this exists, but I'm using a config.php and a config-dev.php and excluded the config-dev.php in my FTP app as mentioned last in the API https://processwire.com/api/variables/config/

simply make a PR

massage and error for admin no ? use them like this u can two $pages->error('bad man'); $session->message('hi'); wire('pages')->error('bad bad.man'); wire('session')->message('hiho'); work.for any api vrable it does