Leaderboard

Okay, thanks to a friend I was able to locate the culprit. Apparently, JqueryCore.js got corrupted during the move. Reuploaded the file from fresh installation files. Works like a charm now.

So I was planning on doing a full write up a while back to compare the different CMS systems: Craft, Processwire, Silverstripe Since I'm here I will just focus on my experiences with ProcessWire. With some experience with developing websites in Silverstripe I figured it would be good for me to have a look at some other options which brought me here. I do have some features which I really want to have with websites which I deliver to my customers: Must haves: Version management -> if a client screws something up I don't want to waste too much time to get things back in working condition. Easy editing of pages for customers. Extensibility with extra content fields in the CMS. Nice to haves: Inline editing. Easy Multilanguage setup. Easy upgrades. First Impressions: The good: Processwire looks pretty good from a power user point of view. I love the fact that you can just use PHP in templates and also the obvious active development is a big plus and it seems to be very extensible. The bad: No support for IIS out of the box. I did find a web.config on the forum but needed to sign up to the forum to download this. Signing up to the forum lists facebook as a sign in option -> doesn't actually work. The first impressions on the look and feel of the admin. Implementing Actually porting a site template over to processwire with the functionality I needed to add: This process went pretty smoothly I loved the pw-append way of working with templates, templates felt really easy to port and set up. Creating menu's etc. was easy. I loved the way that there are multiple ways of doing things which are available with the templates which can be installed. I also loved how easy it was setting up inline editing and adding an edit link to a page. I think my main problems with settings things up where the way processwire handles images. The problems I had with version control plugin + images. Usability testing After having set up the basics I had 2 lovely lady friends do some usability testing by letting them perform some small tasks on the website. Edit some pages -> add an image Swap the position of 2 pages in the menu. Both smart ladies 1 of them had been actively maintaining a magento shop. And their conclusion was unanimous, they both heavily preferred the Silverstripe backend. For me this meant that I continued to work on the Silverstripe version of the website. I didn't continue to complete all the functionality in the Processwire version of the website. Conclusion For me the conclusion of this experiment was that although I loved building the basic website with Processwire the admin experience just doesn't seem user friendly enough to justify the switch.

There haven't been any mayor changes in the way the backend looks in Silverstripe since 3.0. I think one of the main differences between PW and SS on the backend is that when you're editing a page in SS you see the site tree when editing a page. Hence you always have an overview.

I've experimented with this 2yrs ago and it can be done. As I remember there were some minor issues that I haven't solved (mostly because of lack of time). https://processwire.com/talk/topic/13389-adminonsteroids/?page=15&tab=comments#comment-128814

NOTE: This thread originally started in the Pub section of the forum. Since we moved it into the Plugin/Modules section I edited this post to meet the guidelines but also left the original content so that the replies can make sense. ProcessGraphQL ProcessGraphQL seamlessly integrates to your ProcessWire web app and allows you to serve the GraphQL api of your existing content. You don't need to apply changes to your content or it's structure. Just choose what you want to serve via GraphQL and your API is ready. Warning: The module supports PHP version >= 5.5 and ProcessWire version >= 3. Links: Zip Download Github Repo ScreenCast PW modules Page Please refer to the Readme to learn more about how to use the module. Original post starts here... Hi Everyone! I became very interested in this GraphQL thing lately and decided to learn a bit about it. And what is the better way of learning a new thing than making a ProcessWire module out of it! For those who are wondering what GraphQL is, in short, it is an alternative to REST. I couldn't find the thread but I remember that Ryan was not very happy with the REST and did not see much value in it. He offered his own AJAX API instead, but it doesn't seem to be supported much by him, and was never published to official modules directory. While ProcessWire's API is already amazing and allows you to quickly serve your content in any format with less than ten lines of code, I think it might be convenient to install a module and have JSON access to all of your content instantly. Especially this could be useful for developers that use ProcessWire as a framework instead of CMS. GraphQL is much more flexible than REST. In fact you can build queries in GraphQL with the same patterns you do with ProcessWire API. Ok, Ok. Enough talk. Here is what the module does after just installing it into skyscrapers profile. It supports filtering via ProcessWire selectors and complex fields like FieldtypeImage or FieldtypePage. See more demo here The module is ready to be used, but there are lots of things could be added to it. Like supporting any type of fields via third party modules, authentication, permissions on field level, optimization and so on. I would love to continue to develop it further if I would only know that there is an interest in it. It would be great to hear some feedback from you. I did not open a thread in modules section of the forum because I wanted to be sure there is interest in it first. You can install and learn about it more from it's repository. It should work with PHP >=5.5 and ProcessWire 3.x.x. The support for 2.x.x version is not planned yet. Please open an issue if you find bugs or you want some features added in issue tracker. Or you can share your experience with the module here in this thread.

I'm someone who has been developing websites for a while, mostly doing full stack .NET development and ASP scripting before that, while using Silverstripe and some other PHP frameworks for some smaller projects which worked well enough for quite some time. Now I have some time on my hands and decided to evaluate some different CMS options. Diving in as a newbie into: Wordpress Processwire CraftCMS After a short while I decided that Wordpress was out while I'm still evaluating Craft and Processwire. My question is, is there any interest here in reading about my experiences in trying to get the feature set I want up and running, with these other systems?

@usualCommission Have you enabled "Allow page numbers" in template settings?

Updated ACF to make it compatible. (Hope this fixes it.)

I have not seen SilverStripe's backend since version 3.0 but that version was really centered around intuitive page and content management, so I guess it is still solid at doing so. Drafts and page content versioning of SilverStripe has always been built-in, and that's the only thing I really miss in PW. ProcessWire has this covered with a commercial module, but still... I prefer ProcessWire to SilverStripe because of two things: PW does not introduce breaking changes between mayor versions while SS does because of refactoring how things work. Also, PW does not require a template language while SS relies on its own implementation. Anyone can add a popular templating engine to ProcessWire if one wants to.

There's no difference only preference.

There is very little difference: http://processwire.com/api/ref/wire-data/set/ This one sets the property value directly. The $key is converted to a string (e.g. $this->myString = 'my value';) $this->$key = $value; This one uses the method set() to set both a key and a value for you. I'm not sure if the $key is manipulated in anyway behind the scenes, e.g make it 'property' friendly. I've had a quick look and couldn't find anything to that effect. $this->set($key, value); You can also do (Set a property using array access) : $this[$key] = $value; Edit: Reading your thread title, there is no right way. All ways are correct and are documented ?

So it's been a little while since I did this testing, but I will try to elaborate: I had things set up in a way that you could click "edit page" and double click the main content field to edit that. So I think I was super helpful in that regard. It sort of backfired though because it felt less secure to double click to edit to one of the women I asked to edit the site. The changing the sort order of the pages in the menu was also a problem because of the entry point into the CMS. Because when they came to the "Edit this page" screen, there wasn't any obvious menu structure of the website anywhere to be found. I think I also asked them to revert a page to a previous point -> this also wasn't obvious where to do this. One of them thought the experience in Silverstripe felt a lot more secure because of the draft/publish mechanic aka less fear of screwing up and the separation of edit here -> see changes there was very separated. Overall the CMS experience felt messy to them. --- So looking back: it might have been more of a thing that I tried to set up some extra's which I thought would make things easier to edit that wound up feeling less secure.

UX wise the best would probably be opening the folder after some time hovering over it.

Agree. @tpr maybe an idea for AOS to add some hints to the tree when moving items around? I have no specific idea yet ?

Thx for sharing ? Would be interesting WHY they preferred it ? Maybe they where just used to the old way of doing it. This does not mean that another way could not be easier/better in the long run. I remember when I first installed Office 365 I was quite upset because everything looked different then on the old Office 2007/2010 but now it's the other way round: I love the new Office and when I have to work on an old computer with old Office I'm totally bugged ?

Since PW >= 3.0.105 you can easily use the following hook. $wire->addHookBefore('InputfieldSelect::render', function($e) { if ($e->object->name != 'myfield') return; // quick exit if fieldname doesn't match $restrictedIDs = array(); // array of option values to be modified, page IDs in case of pagefield $optionAttributes = array_fill_keys($restrictedIDs, array('disabled' => 'disabled')); $e->object->addOptionAttributes($optionAttributes); }); Related commit: https://github.com/processwire/processwire/commit/07ab8ef9fcefff6a97c688599fb08fb0d462332e#diff-79808b1661a74c0668ee6157537ae478R390

yes, will test later today. the sites with the error are all running 5.6; the sites running 7.x seem to work ok with past 0.9.4

@bernhard download() and show() both work outside of PW.

The build in color highlighting and picker should work fine in CSS or HTML files. There was a issue for using it in PHP files, but is now closed. Sorry for not being more helpful, I usually try to avoid using inline styles. ?

Whats your PHP version ?

Sorry to bump an old thread but 3 years since you posted this just saved my day! I wonder if there's a way this could be made more obvious in the dashboard UI?

Hi all - I've just committed a pretty major update to the Console and File Editor panels. 1) Adds all ACE editor themes with a config setting to choose the theme 2) Options to set the font size and line height 3) I have refactored the sizing of various divs in both these panels that should solve lots of minor layout bugs especially when resizing the panels. *Be sure to do a hard reload to get the latest CSS/JS files. 4) Updated the core SplitJS library which now adds support for dragging by fixed increments which lock to the code line height - before I was hacking this on and it wasn't anywhere near as nice. 5) Various bug fixes for the keyboard shortcuts for resizing the console panes. Also, just a quick note to say that this version doesn't yet include the PW variables code completion. That will come in the next version. I am on a semi-vacation at the moment so haven't had any dedicated blocks of time to get that quite as I want yet. Please let me know how this new version goes for you!

We used http://barbajs.org/ for the transitions. This was for me the best tool to create good transitions. It also includes a preloading/prefetch option: http://barbajs.org/prefetch.html. When the user hovers over a link, it preloads the page. The time difference between hover and click is about 250ms to 750ms in our tests. This is in the most cases enough to load the full .html document. Here is an interesting website to test it yourself: http://instantclick.io/click-test This is how a transition works: The user hovers over a link The browser prefetches the site (Including Base64 placeholder images) The user clicks the link (The time difference between hover and click is long enough to load the document) The actual page transition out The loading screen transition in (In most cases it will skip this step because the page is already loaded) The new page transition in We can change the direction of the transition with data-attributes: <a href="/arbeit/" class="button-enter introduction-button" data-transition-direction="left">Arbeit</a> When you have other questions please feel free to ask ?

I know you already rest your case, but still wanted to point out that Uikit is actually very configurable, meaning that you can pick and choose the components you need. You don't have to include the full framework, and when using SASS or LESS you can easily recompile the framework at any time. There's also another thing that in my opinion makes it a great fit for ProcessWire: Uikit also includes the concept of hooks. You quite literally modify it the same way as you'd modify ProcessWire. The point behind front-end frameworks is that you don't have to reinvent the wheel every single time. In most cases our grids, carousels, cards, and whatnot are not really that different from project to project. Sure, they are styled differently, and may even behave differently, but the basic structure and function is similar. So, why write a new component every single time when you can reuse the old structure/behaviour and just give it a brand new bespoke look and feel? What you're essentially claiming is that every Uikit site looks the same (or requires a lot of hacks to not), yet I disagree. Again if you take an out-of-the-box version of Uikit and use the ready-made default theme (you did notice that using it is completely optional, right?) then yes, it's going to look like... well, an out-of-the-box Uikit with a ready-made theme. Just don't do that, and you'll be fine. Yes, with a framework there will always be some amount of configuration and hooking/overwriting involved, but that's a small price for the benefits you reap. For arguments sake: if we thought that all pre-made components were pure evil, we shouldn't be using ProcessWire either. ProcessWire doesn't dictate your sites look and feel, but it sets a baseline for how it'll work behind the scenes. Uikit does the same for the front-end. Both are easily configurable and modifiable. One might even go as far as say that they are natural allies – two parts of a whole. For the record, before writing this post I was not fully convinced of Uikit: I've been using Foundation, which in my opinion is superior in many ways, and has a rather different method of modification – essentially a massive config file for modifying pretty much every single thing you can imagine. But diving into the Uikit docs made me like it a lot more, and not least so because it really does have certain similarities with ProcessWire itself. In short: Uikit is a great choice for the new processwire.com.

Processwire lets you make websites not the way how processwire works, but the way how you work. Processwire has no system restrictions and does not impose any system rules, it gets completely out of the way how you make websites. This is what Processwire sets apart from so many other systems out there and the reason why we love it so much. Frameworks like Uikit are a set of pre-styled and themeable components. If you want to build a design, that stands out, you end up fighting with default styles and undoing things. This in contrary to Processwire. So, why not chose a system that gets out of the way how you make a design that stands out, in the first place ? Yes I know, Uikit is great for working in a team on the accepted format for CSS, but I am sure that there are systems out there that both get out of the design way and are good for working in a team. Think about systems out there with a configurable set of utility CSS classes. Some of them even have the tools to quickly build your own. I rest my case.

Hello, there is also one "alternate" solution, using Node.js and Puppeteer with headless browser. In this case, export to PDF is only one segment what can be done with that tools (remote login, automated processing, deep testing, etc...). If you have Node.js on your machine, here is example (Windows) where project directory "printer" is in C partition (C:\printer). C:\> mkdir printer cd printer npm i puppeteer easy-pdf-merge After this, inside project directory are all required node modules (Puppeteer, Chromium browser, Easy PDF). Last step is to create index.js file and place it inside project directory ( C:\printer ) // index.js const puppeteer = require('puppeteer'); const merge = require('easy-pdf-merge'); // configuration // *** EDIT THIS: var admin_url = "http://my_site.com/admin_url"; var user = '*****'; var pasw = '*****'; // desired pages // *** EDIT THIS: var pdfUrls = [ "/page/edit/?id=1054&modal=1", "/page/edit/?id=1016&modal=1", "/page/edit/?id=1019&modal=1", "/setup/field/edit?id=1#inputfieldConfig", "/setup/field/edit?id=1&modal=1#inputfieldConfig" ]; var pdfFiles = []; // START async function main(){ const browser = await puppeteer.launch({headless: true, args:['--start-maximized']}); const page = await browser.newPage(); await page.setViewport({width: 1366, height: 768}); // login await page.goto(admin_url, { waitUntil: 'networkidle0' }); await page.type('#login_name', user); await page.type('#login_pass', pasw); // login submit await Promise.all([ page.click('#Inputfield_login_submit'), page.waitForNavigation({ waitUntil: 'networkidle0' }) ]); for(var i = 0; i < pdfUrls.length; i++){ await page.goto(admin_url + pdfUrls[i], {waitUntil: 'networkidle0'}); var pdfFileName = 'page' + (i + 1) + '.pdf'; pdfFiles.push(pdfFileName); await page.pdf({ path: pdfFileName, format: 'A4', printBackground: true,margin: {top: 0, right: 0, bottom: 0, left: 0}}); } await browser.close(); await mergeMultiplePDF(pdfFiles); }; const mergeMultiplePDF = (pdfFiles) => { return new Promise((resolve, reject) => { merge(pdfFiles,'processwire.pdf',function(err){ if(err){ console.log(err); reject(err) } console.log('Success'); resolve() }); }); }; // run all this and exit main().then(process.exit); *** Note: edit this script and write your login parameters and desired urls. After all, run script (inside C:\printer>) node index.js After a while (for this example, ~10 sec.) you will find PDF files in project folder (partials and 1 merged with all). As example here is attachment. Regards. processwire.pdf

WP is great for things. But here we talk about websites ?

Great work @theo! I'm interested to see how this plays out. Will you be sharing the steps/code used to make this? I added your technique to my document "Techniques for flexible page layouts in Processwire" https://docs.google.com/document/d/1peY-FUpevKgy87cKOxIVz8jwcv2-3c61zbiJr3QKO6c/edit?usp=sharing. Will this also handle the case where you have full bleed rows with contained columns on the inside?

Just uploaded v068 which adds template edit link tooltips to the main pagelist items plus has some CSS improvements to a few CKE plugins (some seem to be written at least 10 yrs ago :)). And also see the ProcessPageList.js attached that was modified to enable opening collapsed pagelist items when hovering over them during drag-and-drop. It's still not perfect but it's still much better than the original imo - please feel free to modify the code (see line 1035, "change" property of "sortOptions"). The file's location is "/wire/modules/Process/ProcessPageList/". The main problem is that I check the next item after the placeholder (.PageListSortPlaceholder) so expand-collapse occurs only when moving the placholder above on item and not directly on it. I think this could be improved somehow. The reason I uploaded this here is because AOS v068 contains a few lines of CSS that modifies the appearance of dragging. Of course it works without AOS too. Here is what it looks now: ProcessPageList.js

Hi again everyone - I have spent quite a lot of time on this the last few days and it is now much more robust and feature rich. In an effort to encourage some testing from you guys, I have attached an export of Ryan's blog profile that you can install into an existing PW site. Download the attached zip file Grab the latest version of Page Tree Migrator from Github (https://github.com/adrianbj/ProcessPageTreeMigrator) and install. Make sure your templates directory is writable by the server Run the module from the your Setup menu Choose "Import" and continue to Step 2 Choose the Parent Page - choose "Home" which will install the blog as a first level child of your homepage. Make sure "Everything, including all data pages" is selected for Components to Import. From Data Source, choose "Zip File Upload", browse to the blog.zip file. Click "Upload and Create Content" and wait a few seconds. That's it - you should have a fully functioning blog set up at: Home > Blog It comes complete with the same test entries, images, gallery, tags, categories etc that Ryan's original one does, although I did add in one extra photo, embedded into an RTE and resized - the photo comes from Joss' Foundation 5 profile. The one thing you'll notice is that the embedded Youtube link doesn't work, because the Video embedder module isn't installed. Page Tree Migrator will install core modules as needed, but obviously can't install other ones - yet You'll notice that the blog is installed with its CSS and script files in a subdirectory of the templates folder to avoid an overwriting of existing files. Please test and let me know what you think - Thanks! blog.zip

I think these guys covered it really well, but here's an overly simple alternate example in case it helps. class YourModule extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return array('title' => 'Your Module', 'version' => 1); } const defaultValue = 'renobird'; public function __construct() { $this->set('yourname', self::defaultValue); // set default value in construct } public function init() { // while you need this function here, you don't have to do anything with it // note that $this->yourname will already be populated with the configured // value (if different from default) and ready to use if you want it } public function execute() { // will return configured value, or 'renobird' if not yet configured return $this->yourname; } public static function getModuleConfigInputfields(array $data) { // if yourname isn't yet in $data, put our default value in there if(!isset($data['yourname'])) $data['yourname'] = self::defaultValue; $form = new InputfieldWrapper(); $f = wire('modules')->get('InputfieldText'); $f->name = 'yourname'; $f->label = 'Enter your name'; $f->value = $data['yourname']; $form->add($f); return $form; } } If you have the need to manage several configuration values, then you can save yourself some time by using a static array of default values like in the examples before mine. Also this: foreach(self::$configDefaults as $key => $value) { if(!isset($data[$key]) || $data[$key]=='') $data[$key] = $value; } could also be written as this: $data = array_merge($data, self::$configDefaults);

My mind works in mysterious ways Not every site I build is the same, there are always subtle differences. For things like blogs and galleries being able to export a basic page heirarchy (& fieldset) and recreate it on a new site build would be a huge, huge time saver.