Leaderboard

Today we launched one more website. Plana Press is a small illustration books publisher from Porto. http://planapress.org/ This site is very simple, nothing special technically besides the fact that the initial image changes randomly with different sessions. Also the link underlining color follows the color of that same image. You won't see these differences during the visit to the site, so I'm sharing the way I used to check all the images and colors during development: add ?v=1 to ?v=9 to the end of the homepage url to see all variations: http://planapress.org/?v=1 ... http://planapress.org/?v=9 -- In 2010 they published a book with some sketches of mine. See it here http://planapress.org/livros/big-hands-small-mobile/

thank you! i am new to processwire, i like this cms!

Thanks for the suggestion and the link, Pete, so far our front-end search needs were limited to the title field, but this is going to change soon as lots of social features are being implemented, so I will definitely need to learn all about the cache fieldtype. enricob, the site is currently in open beta and lacking some functionality and server tuning we want to have in place before sharing (especially as an example of what PW can do). A lot of new features are still being implemented and hopefully the site should be well-tested and ready to showcase within about a month. I am eagerly looking forward to posting a case-study about it in the forums then, and will drop you a note as a heads up.

There's a first time for everything.

This is one way - I got this from someone in the forum (can't remember who, sorry). Create an integer field called 'views' and add it to your template along with this code in your template file. You can then add that field to visible in your page list: under the Advanced tab in your template. <?php if($user->isGuest()) { // Count page views only if guest $page->views += 1; $page->of(false); $page->save('views'); $page->of(true); } ?>

wireshell 1.0.0 is out See Bea's post -------- Original post ----------- Now this one could be a rather long post about only an experimental niche tool, but maybe a helpful one for some, so stay with me Intention Do you guys know "Artisan" (Laravel) or "Drush" (Drupal)? If not: These are command line companions for said systems, and very useful for running certain (e.g. maintenance, installation) task quickly - without having to use the Admin Interface, first and foremost when dealing with local ProcessWire installations. And since it has a powerful API and an easy way of being bootstrapped into CLIs like this, I think such a tool has a certain potential in the PW universe. It's totally not the first approach of this kind. But: this one should be easily extendable - and is based on PHP (specifically: the Console component of the Symfony Framework). Every command is tidily wrapped in its own class, dependencies are clearly visible, and so on. ( Here was the outdated documentation. Please visit wireshell.pw for the current one )

There's always the possibility for bugs when updating any software. That why you should always update on a staging/dev environment before doing it in production. I've not experienced any reworks in ProcessWire which would've broken anything without at least incorporating a fallback, so modules should at least work for a whole mayor release cycle. In the modules directory there's a field indicating compatible versions for each module. Regarding the savety issue. ProcessWire does even provide lots of functions to make it easier for users to secure their code (CSRF, session fingerprints, sanitizers) and like mentioned above already, there are currently no known security issues with ProcessWire.

We're using a pretty opinionated yeoman generator somewhat similar (but different... i.e. no coffescript ) to the one from fixate. It's more or less like fireshell. The generator pulls a fresh copy of processwire + evergreen modules, sets up the directory structures, downloads npm & bower modules and creates basic templates + includes that we need for most of our projects. For the database part we're currently planig to integrate wireshell as soon as it leaves the beta status.

I think he's talking about FieldtypeEvent the kinda example for building own fieldtypes.

There are currently no known security issues in any version of PW, but I still like to update because of all the new toys (https://processwire.com/blog/) and bug fixes. Personally I like updating via git pull, but this module also makes it super easy: http://modules.processwire.com/modules/process-wire-upgrade/ Enjoy the ride

The other tool to add to your belt is ModulesMigrator: https://processwire.com/talk/topic/8410-modules-migratorinstaller/ It will install, configure settings, and update to the latest versions all modules that you have selected. I have tagged it as alpha, but mostly because I haven't had any feedback on it. Maybe if this brings it back to life and I get some reports on it, I can get it released - it really is pretty straight-forward.

For shure not the best way - but i'm no pro who work on projects every day....so it works good for me and my skills. got a local installation with uptodate core + my standard modules + german language files at one place 1. install new blank pw installation 2. copy and paste the /site/modules/ and /site/templates/ folder 3. install all new modules + language 4. if needed import special content from my local repository with https://github.com/adrianbj/ProcessMigrator (like site-settings-page, fields/templates for a imagegallery and so on) 5. ready to work on the new page as you can see not really fancy not really streamlined but for a one man show with less projects it did the job.

https://github.com/adrianbj/ProcessModuleToolkit It allows bulk automated migration installation and upgrading of modules (and their config settings) from one PW install to another, so it should be very handy in setting up new sites with your standard collection of favorite modules and settings. Allows includes batch installing by a list of module class names. Go to the Setup > Module Toolkit and follow the prompts. During the import, you can choose which modules from the collection to import. You can optionally import the module config settings from the source install. The one caveat is if a particular setting includes a reference to a page, template, or field ID, it won't work, but you can easily update this setting on the destination install. Batch install new modules directly from the modules directory with a list of module classnames or URLs to module zip files. You can optionally, automatically update all of the imported modules (if they are in the ProcessWire modules directory) to their latest available versions. It copies the module files so you can use it to migrate modules that are not available in the PW modules directory, or on Github. Great for all those custom helper modules you've created. Full restore feature in case something goes wrong / you change your mind. I maintain a dedicated test PW install for installing and configuring modules which I can then export for use in my projects using this tool. Please test and let me know what you think!

I have been spending some long evenings building PadLoper. It is my personal project to challenge myself as a developer, but also something I believe ProcessWire really misses: a solid eCommerce platform. I am happy to announce, that I am not very far away from public release, so I did create a little teaser site and email list for all of you that are interested: https://www.padloper.pw/ As many of you now, I also have bunch of eCommerce modules called "shop for processwire". Those remain open source modules, but I am not actively maintaining them (like I really haven't since 2012). All the code in PadLoper is new and it's totally build from ground up. If someone wants to maintain or develop shop for processwire further, I am more than happy for that. There will be some open source components coming from PadLoper also: at least payment modules, but I might also open source the shopping cart module. Padloper released 4th October, 2015: https://www.padloper.pw/

Thanks for building this module Soma! And the detailed documentation is very helpful. I'm using it on a small campaign site here: http://kvarnholmen.kalmarlansmuseum.se/

You got this a little bit wrong: The $config urls are not there to set something, they just get you the url, so you don't need to write it (and it's more prove to changes, even if they aren't likely). It's not shorter, but you can just care about the path relative to the templates folder. <link rel="stylesheet" type="text/css" href="site/templates/styles/style.css"> <!-- becomes this --> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates; ?>styles/style.css"> Your proposed images path won't be possible as files are saved in page-specific folders, therefore the page's id as one folder. Otherwise you can't have two pages with files named the same. This is a needed behavior to make file uploads scale as well as everything else in ProcessWire. To elaborate more about why it's not a suggested idea to move these locations around: - Everything outside of the site/ folder is part of the processwire core and is therefore not save from potential updates. Therefore anything specific to your site should be inside this folder. It's save there and additionally easily moved to another installation and easy to backup without adding the cms files itself. - The .htaccess file does incorporate quite a few rules (depending on the location of files) to make it as secure as it is. - There's an option to secure files of hidden / unpublished pages from direct access, which is dependent on the path files are stored in. - There's an option to have images distributed over multiple folders, so it scales even beyond some filesystem limitations (only needed for sites with thousands of pages, but still), which is also dependent on a fixed location. - The folder structure make a lot of sense, even if it may seem verbose if one looks only at the single entity "uploaded files".

It's not suggested to change any paths, but you can use all the config variables here http://cheatsheet.processwire.com/#config (the url ones) to make the urls for template files more descriptive. Regarding the file fields: You'll not have the need to write those urls, as these are dynamic anyway. Just use the api to get the urls: $page->files->first()->url;

You got mucho talent.

The sort column isn't explicitly set by the module. It's added by FieldtypeMulti::getDatabaseSchema(), which is a parent class of the event fieldtype.

FieldtypeMulti hints to fields like a image, comments or pagetable field. The http404 hints at it's either the 404 page. Or a URL that is called that doesn't exist and that renders the 404 page but I'm not sure if that would result in a /http404/ (but could be). I have had errors shown and searched for hours until I realized it's a $page->render() I use in templates and the path the error logs was the url of the rendered page (partial) and not the viewed page. Or it's a export or import script (cron script) or bootstrap script. I think those also would end in a /http404/ as I had lots of these in the past. It might be a page name "41-0" in "pages" table. But since that not a PRIMARY it might be a language name field like "name1038" where 1038 would be the language id. See if you can find a page with that name maybe it's in any of the fields. Does it happen frequently, how many times, when. What modules have you installed. What fields. All might be a hint at where to look for.

There is no safe or secure software application. The only thing you can do is use good coding techniques, apply time tested security practices and have a great understanding of whatever you are doing. Proofing your work for errors and have a bit of luck helps also.

I'm not fully understand what you want to do with your pagefield. But I do think a simple str_replace can do alot what you want. <?php $placeholders = array(); // loop through your page field, and create an array with your replacements. foreach ($page->multipages as $p) { // create dynamic keys => values, where the key is the url of a page $placeholders['{' . $p->url . '}'] = $p->theheadline; } // Here {/somepage/} will be replaced with the theheadline of the /somepages/ page $body = 'Vestibulum id ligula {/somepage/} porta felis euismod semper. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. Donec id elit non mi porta gravida at eget metus. Donec id elit non mi porta gravida at eget metus. Vestibulum id ligula porta felis euismod semper.'; echo str_replace(array_keys($placeholders), $placeholders, $body);

I do not update older installations with new releases until I want to add some of the newer features. I today run sites with PW 2.3. There is no security reason to update those.

Thanks a lot for the answers!!! A few further questions: What about the compatibility of (older) modules with an newer/updated PW version (as known in drupal)? Or is there no risk? Is there a way to update the core or the modules automatically or with a click just out of the backend (as known in wordpress)? (I saw that the ProcessWireUpgrade module do this) Is PW so absolute save or so small that actually no one tries to hack it? ;-) By the way, is there a maintenance-mode in PW that i can switch on while performing updates? (I found this module http://modules.processwire.com/modules/maintenance-mode/) Many thanks and best regards!

This is abstracted in the functions sleepValue() and wakeupValue(). You don't need to write own sql statements.

To all those with special cases. Why not just create an Rss manually? Few lines of code really. If after all you have to loop them anyway I don't see why use a module for it.

I can assure you that the recent updates have nothing to do with security ....they are all to do with improvements to performance, added functionality and bug fixing. Some people prefer to use the dev branch of ProcessWire whilst others even stick to older versions

An update: I've now observed this on multiple installations. I've cleared all caches and disabled all third party modules and am still having the issue, so I'll post it on GitHub.

Right, this doesn't seem to be a CKE thing... This is more of a ProcessWire thing, by the looks of it. Granted, I'm just assuming that's the case as the trimming still happens when ACF is turned off, and there are no text formatters assigned. My guess is that the field is being parsed, and when an anchor tag is found, it's being sent through a URL filter. If it isn't a URL, then it's trimmed/sanitised. At this point, I would recommend a module that converts it for you. So, in your field you'd have something like [phone:+27101231234] (just using an example South African number in there), which would be converted accordingly. You could also use Hanna Code, I guess - though I don't use it, and so am not very familiar with how it works. Side note: I wouldn't recommend using callto, unless you're targeting Skype users... tel is the best route to take, I believe, Edit - here's a simple Hanna Code for converting this: [[a tel=+27101231234]] <?php print '<a href="tel:' . $tel . '">' . $tel . '</a>'; The Hanna Code name should be "a" and you should add the "tel" attribute. Also don't forget to add the Hanna Code text formatter to your field.

He means this, which will potentially be a quicker way I think of what you are describing with your process: http://modules.processwire.com/modules/process-export-profile/ So set up a new install with "basic business site features" and export that as a site profile, then when you do a new site requiring simmilar features, upload a fresh copy of PW to a server, copy your exported profile before installation and it should (I think) appear during the installer as an option

the main time siteprofiles don't fit complete on every project....so this could be not the best thing to setup content faster... with PW a website is more like crafting a concept than install only a software. With ProcessMigrator you could choose a Page (with children) and get all relevant fields and template on import/export so you can reuse special content better than the whole siteprofile.

I did exactly that and it's working for me. Could you try to reproduce it in a blank installation by yourself and export it as site profile (http://modules.processwire.com/modules/process-export-profile/)? This way we can eliminate modules and such things from interfering.

@bbeer, I know the feeling, damn you Revo! All the way to hell! But looking on the bright side, while modx was nice to develop on, it feels like my current choice of CMS is simply a classier and more hardened unit ;-) So I'm kinda glad Revo came along and killed Evo. PW will take a bit more killing thou...

@MarcC this is a great idea! Frank, I don't really know where modx is heading to. As for myself, having used Evo for more than 8 years, I was really pissed when Revo emerged. Since then I permanently had bad feelings, when using Evo for a new projects. Development off add ons drop to close to nil. Glad I found PW. Still in the process of getting used to it, but I'll eventually get the hang of it. Guess I will never go back to modx.

It's like it's mentioned in the error message. There's already an entry with the primary key 41-0 in any of your tables and some code is trying to save another entry with this primary key to this exact same table. For me this error was most of the time caused by (own) modules, which did stuff they weren't supposed to do. But basically you could also just search your site folder for "->save(" as this is the part which will result in the error.

Hi @joineffort and welcome! Here's a great thread with some options: https://processwire.com/talk/topic/2868-count-views-of-post/ It's very easy! PS Marty beat me

The processwire way is in 95% to use the API, and not to write directly to the DB. (Using direct access is for rare edge cases or maybe sometimes when create a module) PS: Ah, it is your first post here. Welcome!

Thanks Martijn - not sure why I was using insertAfter there - just matching where it would be if it was visible, but since it's hidden it doesn't matter. I have committed a fix. Also just so everyone knows, I will get to all your suggestions for making this more configurable - just waiting on Ryan's thoughts on some of those issues regarding a core fix or not.

Hi Richard, Back when I initially commented on this I had a frontend system for users to edit their profiles. I went that route initially because I didn't want the majority of users to have access to the ProcessWire admin. I quickly abandoned that approach. I found it was easier to create a base level of access to the PW admin that is just for profile editing. Everything else (including the page tree) is hidden. From there I add back the page tree and other resources based on roles. We have 7-8 internal business applications that run on one install. It works really well actually. I can leverage all the power and simplicity of the admin to create things pretty quickly. It's definitely a lot more efficient that creating frontend versions of them. If you really need something that is isolated from your regular PW install, then you could always do what you mentioned above. Setup a separate install and use it like an intranet. You could probably customize the admin theme to make it look/feel a lot like the front end of your site. You could pull in the profiles from one install to the other via services pages module, or some custom JSON. I think there is a relatively new pages to JSON module that looked pretty robust from what I remember. The other option is the full scale frontend approach. It's not that complicated really. User pages are the same as any other page. I think there are some examples floating around the forums already. I'll dig around here and see if I can find the old frontend system I built.

Here is my proposal. The HTML is in attachments. There are multiple ways how to install the module. Installing from directory (recommended) -------------------------------------- If the module is uploaded in the official *ProcessWire Modules/Plugins Directory* (http://modules.processwire.com), you can use this method. 1. Log in to your ProcessWire admin and go to the *Modules* page. 2. Go to the *New* tab and expand the *Add Module From Directory* section. 3. Enter the *Module Class Name* (can be found in the module's detail page, e.g. FieldtypeMapMarker). 4. Click the *Download and Install* button. Installing from URL ------------------- If the module is not in the official *ProcessWire Modules/Plugins Directory* (http://modules.processwire.com), but the module ZIP is accessible from URL, use this method. 1. Log in to your ProcessWire admin and go to the *Modules* page. 2. Go to the *New* tab and expand the *Add Module From URL* section. 3. Enter the *Module ZIP file URL* (can be found in the module's detail page, e.g. https://github.com/ryancramerdesign/FieldtypeMapMarker/archive/master.zip). 4. Click the *Download* button. 5. The downloaded modules are now listed on top of the page. Click the install button next to any of the new modules that you want to install. Installing from upload ---------------------- If the module ZIP file is not accessible from web or you have it already downloaded, you can upload the file. 1. Log in to your ProcessWire admin and go to the *Modules* page. 2. Go to the *New* tab and expand the *Add Module From Upload* section. 3. Select the *Module ZIP file*. 4. Click the *Upload* button. 5. The uploaded modules are now listed on top of the page. Click the install button next to any of the new modules that you want to install. Installing manually ------------------- If any of the above methods isn't suitable for you, you can install the module manually. 1. Place the .module file in your /site/modules/ directory. If the module contains more than one file (like supporting .css or .js files for example), it should be created in it's own directory under /site/modules/ with the same name as the module (.module file). For instance, the FieldtypeMapMarker module and supporting files should be placed in /site/modules/FieldtypeMapMarker/. 2. Log in to your ProcessWire admin and go to the *Modules* page. 3. Click the *Check for New Modules* button. 4. New modules are now listed on top of the page. Click the install button next to any of the new modules that you want to install. *Note: All third party modules should be placed in /site/modules/. You might also notice that ProcessWire keeps core modules in /wire/modules/ – You should avoid installing your modules there, as that location is reserved for core modules.* How to uninstall a module ------------------------- 1. Log in to your ProcessWire admin and go to the *Modules* page. 2. Find and click the module name that you want to uninstall. 3. Expand the *Uninstall* section, check the checkbox. 4. Click the *Submit* button. 5. It is now safe to remove the module's files from /site/modules/ if you want to. how-to-install.html

Have you tried using the cache fieldtype to combine multiple fields' data into one for things such as searching? It's in the core an Teppo explains it well here: https://processwire.com/talk/topic/5513-fieldtype-cache-please-elaborate/

While it's certainly possible it's not as easy as you may think it is. Passwords are stored as hashes in the database. ProcessWire will never store the plain text password. The hashing is dependent on the salt value stored in the config.php. The salt is generated as part of the installation process and therefore your live installation may have another salt value as the dev one. If this is the case it means all the passwords of imported users would be invalid after moving them. What you can do is to copy the whole users database table and copy over the salt value, too. As long as all hashes of user passwords are generated with the same salt value you can exchange users as you wish. But if you have users in both installations, where the passwords where saved with different salt values, you can not move the passwords over from one installation to another. You would need to change/update the passwords by hand in this case. Everything besides the passwords shouldn't be a problem.

I posted 2 times in another topic about the SMTP settings for Google. Here is the consolidated information from those posts: If you use a Google email address, this will work: Other major providers are setup similar (you just need to check what their SMTP requirements are - this information is easily found, otherwise ask your hosting provider for correct setup and ports) ------------- Second Post ----------------- I will & here is additional information regarding Gmail. There are specific variations that will work and sometimes people don't understand why an option is needed. These links should educate anyone on why certain settings work and others don't. https://support.google.com/a/answer/176600?hl=en http://email.about.com/od/accessinggmail/f/Gmail_SMTP_Settings.htm http://email.about.com/od/accessinggmail/qt/et_gmail_imap.htm http://email.about.com/od/accessinggmail/qt/How_to_Access_a_Gmail_Account_with_any_Email_Client_via_POP.htm

Tycho, among others. Mostly instrumental stuff (Lounge, Jazz, Deephouse, Soundtracks) to prevent subconsciously concentrating on text/lyrics.

http://lmgtfy.com/?q=processwire+hide+pages+in+admin First search result shows a thread, where you even liked my posts where I explain and show an example module of how it could be archived. So there's no way to do it without a mean hack. I'm still waiting for Ryan to implement something to make this easier and brought that up on github again.

I'm not sure what the value of sorting by "id" is, but if it's for chronological reasons, consider using "created" instead as your sort field. That's going to be more reliable to achieve the same purpose.

Another option that would bypass Pw caching, even ProCache is to send an ajax request to handle the counter. If you use jQuery, this would be something like this: //Javascript <script> $(document).ready(function() { var data = {'action' : 'handleCounter'}; var url = '<?= $page->url?>'; $.post(url, data); }); </script> //PHP if ($config->ajax && $input->post->action == 'handleCounter') { //... //put your php code in here //... exit(); //Quit since this was only a request to update the counter } To make this work you would need to disable caching for the POST "action" variable. This is done in the template settings under Cache > Cache disabling POST variables

most of the time I end up wearing my earbuds for two hours, but forget to turn any music on *edit: Martijn, love that Lollywood song and video

Create a field "counter" with type "integer" and set it as "hidden, not shown in the editor" or "always collapsed, requiring a click to open", as you prefer. Put this code on your template: $page->counter += 1; $page->of(false); $page->save('counter'); $page->of(true); echo $page->counter; voilá