Leaderboard

Hello, in one of my current projects, we have a test and production stage with their own ProcessWire installations, and we regularly want to migrate template/field configuration to the next stage without migrating content as well. ProcessWire supports this via the import/export functionality in the admin GUI. However we (and some others) would like to do this as part of an automated process. There seem to have been some discussion on this topic and two existing modules that get pretty near our requirements: https://github.com/mindplay-dk/SystemMigrations/blob/master/SystemMigrations.module https://github.com/LostKobrakai/Migrations However, they try to solve more then we need and for mindplay-dk's module, development seems to have discontinued. At that point I decided to build a more simple module with reduced scope that basically just makes ProcessWire's import/export automation-ready. Thanks in advance for trying this out and any feedback! About this Module CAUTION: This module is incompatible with repeater fields and ProFields. The module enables you to transfer template and field configuration from one processwire installation to another in an automated way. Changes to templates or fields are exported to the file system immediately (so they can be added to source control together with changes in the template files) The import script is designed to run from the command line (so it can be invoked from your build/deployment tool). On invocation in import mode, a DB backup is created template/field changes from the persist directory are imported into the DB In restore mode, the import script can restore any of the DB backups previously saved How to Use Make sure the module is installed in the source and destination ProcessWire environments. After installation of the module, you should check if the module's default persistDirectory configuration setting fits your requirements. The module will automatically export all fields, fieldgroups, and templates to JSON files in the directory specified by that setting. Note that the same setting is used by the import script as well, so if you change it, make sure you change it in all affected ProcessWire environments. The JSON files can be transferred to the destination ProcessWire environment. Running the import script from the command line will import template and field data in the destination ProcessWire environment. Manual Installation Caution: Beta software - do not use in a production environment without prior testing and regular back-ups. Caution: This module is incompatible with repeater fields and ProFields. In case automatic installation does not work, get the code at https://github.com/jaromic/pw-autoexport-tf/ and follow the instructions in README.md for manual installation. Manual Uninstall Delete the following files and directories from your module directory: AutoExportTemplatesAndFields/ AutoExportTemplatesAndFields.module Download Install from the module directory, clone the repository via GitHub, or download ZIP.

A view month ago, I finished a website for a local Car Dealer. It is based on handcrafted CSS with pocket grid. The dropdown menu is made in CSS, without Javascript. It also has a separate menu for tablets and one for mobile phones. On the intro page is a jssor animation. All background images are made by me. All other content is from the owner. Here are some screenshots how I designed the initial version: http://buescher-gruppe.de/

Now I found out that the Tags get saved for me also under PW 3, but the form fields (Tags, Descriptions) got not populated via AJAX, so when the page finally gots saved in the page editor, the previously saved values get blanked out again. I HAVE USED THE WRONG HOOK! Damn! It has to be addHookBefore and not addHookAfter. I changed the code in the first post so that it now is working with PW 2 and PW 3. Sorry for the confusion. (I copied the function out of an old module into a $wire->hook for site/ready.php. Hereby I must have accidently changed to the wrong hook event. Damn!)

I feel like this would be the most consistent solution - it sounds like a panel you won't need most of the time, so just activate for when you need it. I'll definitely add this to my list - the more I think about it, the more I am realizing how useful it will be.

Besides using the Fieldtype module @LostKobrakai suggested (I haven't used it myself), you could create a simple Process module to list pages with the product template alongside the calculated VAT inclusive price. Check out the example module code shared by @renobird here. Edit: I just installed RuntimeMarkup and it works great for math calculations. So using this module would be the way to go if you want to see calculated values in a Lister.

http://modules.processwire.com/modules/fieldtype-runtime-markup/

From my experience, @Robin S's solution is definitely the way to go!

I'm no expert in this, but the way I see it is you have a base price and then one or more 'modifiers' that act on the base price. A modifier could be a tax rate, an export tariff, an addon handling fee for a large item, or something else. You don't work out the results of these modifiers for each base price ahead of time, you just apply them using PHP math operations as needed depending on what options the website visitor has selected. I think the performance impact of basic math operations like this would be negligible.

This module provides a very simple interface to a set of named counters. You simply call a single function, next('name'), to pull the next value out of a counter - or to set it up if it does not yet exist. Next() takes a few extra parameters to allow you to increment by values other than 1 or to start at a certain number. This provides some similar functionality to the built-in page naming feature of PW, and to this module recently posted by Stikki but I think it offers a little more flexibility than either. Having said that, I do like the simplicity of Stikki's new auto-increment module. Module Availability Here is my module on Github. Here it is in the module repository. Example Usage Here's how this module can be used to title and name a new page by adding a couple of simple hooks to site/ready.php. This example applies to new pages using a template called 'invoice' that can be quick-added to the page tree. In order to get the following to work, you must edit the template that will be the parent of the 'invoice' template and setup the template for children to "invoice" and set the "Name Format for Children" field to something other than the default blank value (I use title as my value.) <?php /** * Function to recognise our special template. */ function isInvoiceTemplate($template) { return ($template == 'invoice'); } /** * Pre-load the page title for invoice pages with a unique value * which includes a counter component. */ $pages->addHookBefore("Pages::setupNew", function($event) { $page = $event->arguments(0); $is_invoice = isInvoiceTemplate($page->template); $no_inv_num = $page->title == ''; if ($is_invoice && $no_inv_num) { $counter_name = 'WR-' . date('Y'); $number = $this->modules->get('DatabaseCounters')->next($counter_name, 10, 5000); $page->title = $counter_name . '-' . sprintf("%06u", $number); } }); /** * Prevent ProcessPageEdit from forcing an edit of the name if we got here * through a quickAdd from ProcessPageAdd. We can do this because we * preset the title field in the Pages::setupNew hook. */ $pages->addHookAfter("ProcessPageEdit::loadPage", function($event) { $page = $event->return; $is_invoice = isInvoiceTemplate($page->template); $is_temp = $page->hasStatus(Page::statusTemp); if ($is_invoice && $is_temp) { $page->removeStatus(Page::statusTemp); $event->return = $page; } }); Note, the above code + module is one direct solution to the problem posted here by RyanJ. Version History 1.0.0 The initial release.

Site looks very good, wished I was there when you made it

Ooh, ooh, me first! You should grab a template, give it a document, tag and description fields There's no document library module (that I'm aware of), probably because a module isn't needed for something like this. For your task the basic item you are dealing with is a document record. This is a collection of information: URI, description, tags. In ProcessWire the 'page' is the unit that is typically used to store a collection of information. And in ProcessWire, a page isn't necessarily a complete page that visitors view on the website front-end; a page can consist of only a title field, and you will probably use something like this for your tags/categories. The broadened definition of 'page' in PW is one of the things that can be confusing at first for new users. It took me a bit of time to adjust my idea of what a page can be. So as you predicted, you would create a template to use for document records and give it the fields you need. Then you add one page per document under a chosen parent in the page tree. It's up to you whether you make individual document records viewable as individual pages on the website front-end. You might decide you don't need that and only pull in information from the records to display as part of another page (search results or category listings). A great place to start is Ryan's Skyscrapers profile: http://demo.processwire.com/ http://modules.processwire.com/modules/skyscrapers-profile/ Replace the concept of 'skyscraper' with 'document' and you'll see how PW can be used as a document library. I did exactly that for the first website I built with PW: http://ref.dunestrust.org.nz/

Done! Makes sense - let me take a better look at that existing panel. Unfortunately most of the existing Tracy plugin panels require the entire Nette framework, so it is unlikely I will be able to use that one directly. I initially started with someone else's ToDo panel, but even after I had stripped out all the requirements for other Nette components, I still didn't like the way it was parsing out comments, so I ended up writing a new one from scratch I guess I am not totally sure how this would help. At the moment by default, it only scans files inside /site/templates. With that new checkbox, you can now expand this to include /site/modules, but I doubt many will want to add this option. I am think most will want to scan all of /site/templates, but simply exclude some parent folder like /site/templates/scripts/libraries/ where they would add all third party js libraries. Can you explain what folders you might want to exclude that a regex could help with - that would help me better understand how to implement. I am not totally sure on this either - you'll notice when you have Tracy enabled in the backend, there is an additional bar that shows up when the admin makes ajax calls (like for getting menu subitems), so theoretically I could have an "email" panel also show on the ajax bar - currently I disable all of the custom panel (except performance) from appearing on the ajax panel, but I can make an exception for an email one. I am guessing this shouldn't be too hard - just need to hook into wireMail. Perhaps you guys ( @tpr and @bernhard ) could come up with a list of required features?

Thank you for the help.

Don't apologize - feedback is what I need Yeah, good point about modules - I think it makes sense to have the option to scan the modules directory too - I don't recommend this for most users as it can slow things down a bit, but the latest version now includes a config settings checkbox to allow this if you want. I also fixed the error if you empty the ignore dir list as well as improving some other elements of comment parsing.

@adrian Thanks & it works

You probably need to call shopware's autoloaded before starting the zend session. Also make sure that you're not trying to call a namespaced class.

Hey, Sorry to hear. Most hosting companies will tell you that the system is running fine (developers: it's the system. operations: it's the application). Have you looked into the server logs by apache or mysql? Ask the hosting provider how they know it is being caused by ProcessWire. Is there enough ram?

Thanks, horst Using that version in our project, I have developed and tested for 2.6 only so far. It does not use namespaces, so 3.x will probably not load the module. I will adapt and test with 2.7 and 3.x as soon as my time allows, hope to get to that within the next two weeks too.

Ok. // code snippet that belongs into the site/ready.php file: // a hook that reads IPTC keywords on images upload and populates them into the images tags field $wire->addHookBefore("InputfieldFile::fileAdded", function(HookEvent $event) { $inputfield = $event->object; // handle to the image field if(!$inputfield instanceof InputfieldImage) { // we need an images field, not a file field return; // early return } if(version_compare(wire('config')->version, '2.8.0', '<')) { $p = $inputfield->value['page']; // get the page, PW < 2.8 } else { $p = $inputfield->attributes['value']->page; // get the page, PW >= 2.8 | 3.0 (or only from 3.0.17+ ??) } $image = $event->argumentsByName('pagefile'); // get the image // check for IPTC data $additionalInfo = array(); $info = @getimagesize($image->filename, $additionalInfo); // read image markers if($info !== false && is_array($additionalInfo) && isset($additionalInfo['APP13'])) { // APP13 is the IPTC marker $iptc = iptcparse($additionalInfo['APP13']); // IPTC field 025 = keywords collection if(is_array($iptc) && isset($iptc['2#025']) && is_array($iptc['2#025']) && count($iptc['2#025']) > 0) { $tags = array(); foreach($iptc['2#025'] as $k => $v) { if(empty($v)) continue; $tags[] = trim(strtolower($v)); } $p->get($inputfield->name)->trackChange('tags'); // prepare page to keep track for changes $image->tags = implode(' ', $tags); // add the tags list as string $p->save($inputfield->name); // save the page images field } } }); EDIT: code was modified to detect $page also with PW version >= 2.8 | 3.0 EDIT 2: Now it is working for all PW versions again. Had have the wrong HookEvent used here (addHokkAfter, but must be: addHookBefore!)

Right now I am not particular proud of myself, because I maybe had the first occurrence of an hacked ProcessWire installation known to mankind. But not because of ProcessWire itself, but of a stupid mistake I have made. Anyways I want to share my case here: Over one and a half year ago I developed a medium sized website with ProcessWire 2.6.1 for a small community. In the process of releasing the site I had troubles with getting the installation to run on the shared hosting webspace. Because the hoster hadn't configured their file permissions correct, I was forced to loosen up the file permissions inside the site/assets-folder. Because I was desperate and wanted the installation to work I ended up setting every file and folder permissions inside the folder assets to CHMOD 777. I wasn't very happy with this solution and now I know how stupid it was, but I didn't knew better and at least the installation was running. This week I wanted to make a small change to the site and noticed something strange: There was a file called sites.php inside the root folder. At this moment it was clear to me, that my installation was hacked. I immediately downloaded the whole infected installation and compared all files with my local clean installation using a diff tool (Kaleidoscope). After comparing I noticed that inside the index.php one line was inserted which included a functions.php inside the site-folder. Also I noticed that inside the site/assets/files-folder there were several php-files uploaded with the same naming convention like the generated images variants (f.e. filename-large.jpg). So what did those scripts do? Luckily not much, that is the reason I haven't noticed this hack for a long time. The database is as far as I can tell not corrupted and the site was still working properly. All those scripts were doing, was generating spam aliases and redirecting to a medical shop site using the http host of my site. Interestingly on my research I have found out, that most of those malicious scripts were intended to infect Drupal and WordPress installations. A few of those files inside site/assets/files are explicitly targeting WordPress specific functions. If you are interested I can share those scripts for further investigation. But I am not sure if uploading those scripts directly to this board is against the board rules, so if I should upload them to a external service, I am willing to do so. Meanwhile I am confident to have cleaned the site from almost all malicious scripts (I will investigate further) and I am still removing all spam search results from Google using the search console. Also I am in contact with the hoster and try to sort things out, even if it means switching the hoster (which I would prefer). Please don't be to harsh with me. I know I have made a stupid mistake and learned my lesson the hard way, but I wanted to share this story anyway to prevent others from making the same mistake. So always make sure to secure your file permissions! Regards, Andreas

I guess i might have done the sticky thing, but i assumed that meant it would show up in the selected panels in the module settings; If that's not the case, then it would be hard to 'undo' a scenario where an enabled panel under sticky mode was causing epic page loads, how would you get to the frontend panel to turn it off? i probably will use it only in the regular template files, it will definitely come in handy - many thanks!

This depends on if there is only one VAT %. In germany there are two, or three: 0% 7% 19% If there are multiple VAT % possible, I think it is better to maintain with the saveReady hook, and if one day the VAT will adjusted to another % value, run the bootstrap script again. But if there is only one VAT %, @Robin S solution seems to be better. If this is the case, I would add a property hook to $page, that gives me the VAT-include calculated value. (I think, this is what Robin have in mind too.) EDIT: Ah, totally silly. Robins solution is better, regardless if you have one or multiple VAT % values.

Another solution... Instead of wrapping the link around the textarea on the index template, place the link as a sibling to the textarea and then use CSS absolute positioning to place it over the textarea. index-template <div class="my-text"> <a class="my-link" href=""></a> <?php echo $page->textarea; ?> </div> CSS .my-text { position:relative; } .my-link { position:absolute; width:100%; height:100%; top:0; left:0; z-index:2; }

Rather than having two price fields... price price_including_vat ...have you considered having one price field and one VAT rate (%) field? price vat_rate And then you calculate the VAT inclusive price on-the-fly. Seems like it would be easier to maintain this way.

A simple fieldtype might be "Name", where you enter a firstname and a lastname, which is stored separately and maybe a computed property for the fullname. I think it shouldn't hold more values, as it'll probably become complex just for the amount of fields. Also interesting might be other often extended core classes/modules like Process or Textformatter, with the latter actually being quite simple with often just a single method.

You need a bootstrap script that should be located besides the PWs index.php. I have a template for that: After you have setup all your products, I would write a hook into the site/ready.php. Hook into before pages save, check if it is a productpage, if so, calculate the incl. vat price and populate it to the field, Ready!

Imho the best lightbox script out there: http://photoswipe.com/

@Lance O. If you use PW Version 3.0.22 you should make an update to the last available version. This should solve your problems. The date of your post looks a bit '3.0.22ish' @Hani Thanks for this great module. It is working as expected. Even in the latest 3.0.x I made the inputfield selectable to make all subclasses of 'InputfieldSelect' available. FieldTypeTemplates.zip

Website builders have their place and serve a purpose. They can be a quick fix and allow more people to have a presence on the web. I believe there is no need to fear them or worry that products like ProcessWire will be replaced by them. We could spend all day debating the merits of these products or just continue as we do making ProcessWire a better platform. I've been doing this since 1977 and have seen many things come and go. I honestly believe the webwork market will still continue to function long after these products have matured and 10 other new web building technologies have come along. This market changes everyday in ways that no one can adequately predict. I believe that change is always good, improving what needs to be improved and getting rid of what no longer works. Have a blessed Friday

To extend the above example to hide the name, template and parent fields on the settings page of invoices, you can add the following to the ready.php snippet in the above post. /** * Work out if the template's settings should be tweaked to hide things that should be fixed... */ function shouldHideTemplateSettings() { // Super users retain super-setting-edit powers if (wire('user')->isSuperUser()) { return false; } // Are we even editing a page? if (wire('page')->process != 'ProcessPageEdit') { return false; } $id = (int) wire('input')->get('id'); if (!$id) { return false; } $editedPage = wire('pages')->get($id); if ($editedPage->template->flags & Template::flagSystem) { return false; } if (!isInvoiceTemplate($editedPage->template->name)) { return false; } return true; } /** * Hide some fields from the invoice settings page from non-super-users. * * There's not much point allowing edits to the name field, so we want it immutable (at least) and probably totally * hidden (better.) * * We don't want invoices being moved from their parent, so we hide the parent field. * We don't allow them to use a different template, so we hide the template field. * */ if (shouldHideTemplateSettings()) { $pages->addHookAfter("ProcessPageEdit::buildFormSettings", function($event) { $wrapper = $event->return; // To show the name field but make it immutable $wrapper->_pw_page_name->collapsed = Inputfield::collapsedNoLocked; $wrapper->_pw_page_name->description = ''; // Alternatively, to hide the name field do uncomment the following and comment out the 2 lines above //$wrapper->_pw_page_name->collapsed = Inputfield::collapsedHidden; // Hide the template changer, invoices can only use the invoice template $wrapper->template->collapsed = Inputfield::collapsedHidden; // Hide the parent page, as it is fixed in our page structure $wrapper->parent_id->collapsed = Inputfield::collapsedHidden; }); }

If someone really needs lots of free emails (100.000): https://www.sparkpost.com/pricing And a blogpost regarding future plans https://www.sparkpost.com/blog/my-promise-to-developers-sparkpost-pricing/

For people who want a simple solution out of the box, I would say ProcessWire is not that kind of CMS and that's a good thing. I see ProcessWire as a developer-oriented tool for building custom, complex content websites that have unique requirements and that should be it's strength. CraftCMS and ExpressionEngine fit that niche as well. If ProcessWire were to become a CMS where themes could be swapped at will, I'd imagine that would first pose some technical challenges that would need to be resolved. For example, to what extent does a theme dictate field/template structure, and if someone were to switch to another theme, how would that work? Nico's WireThemes proof of concept module has a nice way of going about that. It's similar to how FormBuilder can map a form's fields to a page's fields when using FormBuilders option to save submissions as pages. When it comes to WordPress and premium themes (like ThemeForest), once you're on a theme, you are stuck with it. No easy portability. Not to mention, each theme is like a CMS within WordPress itself, especially with the trend of mega themes that have recently become popular. Then when add a few plugins to the mix and you'll probably have all kinds of conflicts. Although WordPress is still the king of CMSes for ready-to-go themes, I would say that WordPress is going to be losing its dominance in that arena given the new generation of remotely hosted content management systems, like SquareSpace, Wix and Webflow. Those companies are doing very well because they really cater to people who want something up quick, cheap, easy and with a small learning curve. No coding required. It seems that WordPress (.com at least) is stepping up their game to challenge that. Their new admin system and Jetpack are good examples. Lastly, being the McDonalds of CMSs will cheapen the image of ProcessWire. I do think however we should be attracting advanced WordPress developers. In short, anyone who uses any tools from Roots.io, Underscores, Advanced Custom Fields, WP-CLI, or similar. There are many talented people in those circles who for reasons beyond me, still use WordPress.