Leaderboard

This Textformatter module for ProcessWire enables you to break up a single textarea field (using either TinyMCE or CKEditor) into multiple pages. You include all of the content in a single rich text field and separate each pagination with a line of hyphens (5+). When rendered on the front-end, the user will see pagination links at the bottom of the page enabling them to move forward and backward through the content/article. Also included is the option for title pagination. That means assigning a title/headline to each pagination and giving the user a list of those titles they can click on to move to each section of the article. Example of this module in action Documentation and customization options GitHub Page Module Page Download ZIP Install class: TextformatterPagination

Hey Ryan, thanks for your reply. I know what you mean about the Pyro way being insecure. I brought it up with them a while ago and the only option was to allow BOTH the ID and the Filename. There was no way to set any kind of limitations on image sizes that could be generated, or any way to pre-define the sizes to use to prevent users generating new images. I've been having a play around with images and pages and I see what you mean about having something better - that just saved me weeks of potential dev work Thanks for the comments on the site too! It's currently a bit dated as I basically had about a 6 month period where I was too busy to do any site content other than news posts. I've got a whole stash of new and updated content for it but have been holding off publishing until it was moved off of Pyro. I've only been playing with ProcessWire for a few hours but I'm loving it so far. I finally think I've found what I'm looking for - thanks for creating such an awesome project! (Have a great time in Orlando!)

I agree, I think ProcessWire would be an excellent fit for your needs. With regard to centralized media manager, there's a reason we don't have one built in and that's because we've got something better. You may have to think differently about how you manage them, but once you get it I don't think you'd want to go back to an old style media manager. If you need any help understanding how a particular situation would be accomplished in PW I'm happy to give more info. This is a potential security hole. Allowing URLs to create images on the fly has high potential as a ddos (denial of service) hole that is an easy attack target. Someone can write a quick script to formulate and call millions of those URLs, consuming your server for hours or days till eventually filling up the hard drive (or your hosting quota). Basically, it's a security problem if non-predefined resize dimensions are coming from the client (user input, like URLs) rather than from the server. I substituted some other width/height values in there and can see it will take whatever I give it (no restraints). For example, this call uses 3 megabytes on disk, takes up several seconds of server time, and consumes 3 megabytes of your bandwidth: http://wdwfans.com/files/thumb/21638/3500/3500/fit Here's how you'd approach creating 500x500 images in PW: $image = $page->image->size(500, 500); echo "<img src='$image->url' />"; Our default behavior would be the same as your "fit" method described. I'm not sure there is a legitimate use for the "fill" method as it distorts the photo, something that I can't imagine is desirable on any site. But if you wanted to duplicate that, you'd turn cropping off: $image = $page->image->size(500, 500, array('cropping' => false));

new german updates for actual PW dev 2.4.5 (28 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--core--pages-php.json wire--core--wireupload-php.json wire--modules--fieldtype--fieldtypefile-module.json wire--modules--inputfield--inputfieldfile--inputfieldfile-module.json wire--modules--process--processlist-module.json wire--modules--process--processpagetype--processpagetype-module.json wire--modules--process--processrole--processrole-module.json pw-lang-de-dev-update.zip

For your first scenario I can't quite see what the big benefit of session would be, though that depends on the structure of your page and the way you build this thing in the first place. Some possible solutions I'd consider: If the edit view opened in modal box is an external page (not part of this page or put together on the fly) then you'll have to somehow let it know what it is that you want to edit.. and in that case I'd rather provide it with page ID and field ID (or name) as GET params. If the edit view is generated and filled out on the fly (and submitted by AJAX, I'd assume) you can just grab the content from page using JS without the need to store anything in session variables. In your second scenario I'd also consider using GET params (specify comment ID to quote from) or storing either the comment ID or even the whole quoted text (unless you really need to support storing *a lot* of data) in JS cookie. This is an example of situation where you probably don't need to make sure that quoted text is somehow protected (in most cases user can edit it upon posting anyway), so storing that data in session provides very little extra value. -- Considering sessions vs. other methods of storing run-time data in general: Biggest reason I tend to avoid sessions is that as the amount of data stored in session grows in size, so do the memory requirements (and, in extreme cases, also the disk space requirements) of your site. At least some PHP versions load whole session data to memory when session is started, so you can imagine what having tens of kilobytes, hundreds of kilobytes or even megabytes of data (a worst case scenario, but still) does on a site with a lot of simultaneous users. With sessions you'll also want to make sure that you're cleaning stored session files properly (which, by the way, isn't always as trivial as it may sound) and preferably clearing stored values run-time too, especially if you're storing a lot of content. GET params, on the other hand, don't consume any extra memory.. and storing stuff in JS cookies only consumes client resources. As for why one would prefer to use sessions, biggest benefits are that a) session variables make it possible to "hide" the mechanism behind this all from the user and b) session data is much harder (practically impossible, unless you've made it possible yourself) to tamper with (it's easy to try out different values for GET params or alter data stored in JS cookies). Ease of use is a very real benefit too, of course. Storing data in session variables is often the least painful route. Tradeoffs, tradeoffs.. but then again, isn't that what web / software development is always about?

i finally found some time to finish the greek translation, you can download it also from github processwire-greek-language.zip

Hi all, I've got a bit of a newbie situation for you all today and would appreciate any input you could provide. Right. I use PyroCMS, a very dated, but heavily modified and patched copy on my site. As it stands I'm finding Pyro to be more of a pain by the day (broken features, now impossible to upgrade as they discontinued some stuff we need, etc) and am looking to move to something else. I first started out by planning out, and starting a completely custom CMS built on Laravel. But I've not come anywhere close to finishing and it seems silly to spend months building a complete system, when I can use something like ProcessWire and then build (and, where possible, share) custom modules for any functionality I need added. The site has a custom set of tables. They store theme parks, the 'lands' inside the parks, then the attractions, restaurants and stores inside each land. It also stores hotels and their restaurants, and hotel details such as room types, gps data for locations, etc. A lot of the data isn't utilised on the current site, but I've got it all ready to be used on the new system. Ideally I'm also looking for a way to have all these individual sets of data (which then get shown as 'pages') properly tagged for a decent way of searching the site. Am I right in thinking ProcessWire is an ideal option for all these custom data types? One other thing I'm a little worried about is images/media. I've got a TON of photos and galleries on the site, and right now I use PyroCMS's built in file manager, which is essentially a jquery based virtual file browser, but it allows cool things like on the fly image resizing and caching by doing something like this: Original: http://wdwfans.com/files/large/21638 500x500 cropped: http://wdwfans.com/files/thumb/21638/500/500/fit 500x500 filled: http://wdwfans.com/files/thumb/21638/500/500/fill Whilst from the front-end I have no need to do that, it'd be from the backend that I need to browse and insert images into pages that are already uploaded, and set the sizes up. I had a flick through the modules database but didn't see anything obvious that would allow this. I'd happily write a custom module for something like this, but wanted to first check that nothing existed already, or if there was a better method of achieving something along these lines. For my current database-based content I'm literally pulling the DB content directly into the template files. Am I right in thinking process wire handles this sightly better? For reference/info here's some examples of the pages that use custom data: Restaurant: http://wdwfans.com/dining/teppan-edo Attraction: http://wdwfans.com/theme-parks/magic-kingdom/attractions/splash-mountain Resort: http://wdwfans.com/resorts/disneys-all-star-movies-resort I'm excited at the thought that I may have finally found a CMS capable of performing the tasks I need it to do. I'd really appreciate any input or suggestions on if ProcessWire will be able to do what I need, and where I may run into any problems. Many thanks.

With regards to a media manager, this is a topic not everyone agrees on so when I state "something better" I'm stating my opinion, formed largely on the sites I've built over the years. I don't believe I've ever dealt with a site that would have been better served by a media manager than with PW's way of managing assets, especially as the scale increases. But not all sites have the same needs, and we like differences of opinion here so I aways want to encourage discussion and questions. Keep asking questions and decide for yourself. If you are coming from a background of having used a media manager on past sites, I'd definitely encourage you to post more about the things you are trying to solve so that we can direct you towards simple ways of solving them. There are lots of different ways to accomplish things in PW.

Hi Tom! There are indeed several ways to manage this! Your first choice to set the visibility to hidden would be handled by creating a custom module. Your code would hook into the page creation/page save events, check the template for "event", and set the page to hidden. There are several modules in the Modules directory that will hook into the same place which you could look at for examples on how to do it. One that springs to mind is the Date Archiver module. I don't use MarkupSimpleNavigation, but I think it would be able to support what you want somehow. If you check the documentation, it seems you could do it one of two ways: 1. Use the "selector" configuration option. You might be able to specify "template!=event". 2. It looks like you could use "nav_selector" to customise the output for that section of the website.

The above is just the start of image manipulation potential in PW. There are so many things you can do from the API side with images. Just today we added some new cropping options to the dev branch (thanks to Horst, who is one of the best in the world when it comes to image related code). Btw, your site is great and I will definitely visit a lot in the future. We're in Atlanta, but have family moving to Orlando and plan on spending a lot of time at Disney World when we can (we have two young daughters that of course love everything Disney).

Thanks again. If nothing was logged that suggests that $valid_files is empty, or that create_zip never gets called for the json file, but I can't see how that would be possible. Would you mind playing around a little more inside that create_zip function and try to figure out the content of $valid_files when trying to add the json file to the zip. Try this after 2108: if($filetype == 'json') error_log(print_r($valid_files, true)); Also, I see that you edited your post since initially posting. Those errors you did get are strange - seems like you might be trying to export a page with no template. Do you have any ideas on those errors? Thanks again for your help with this. I hope it doesn't turn out to be some version specific bug in xammp

For me it's a great news, very handy module that could come in play in a lot of situations. Thanks a lot!

Also, you are looking for the events that will happen in this precise millisecond try using Datum=today instead of Datum=$t

You forgot to foreach loop over the gigs of today. $heute is a PageArray, not a Page. Cheers Edit: Marcus won the race

Looks like you're looping through $gigs and $gigspast, but are trying to output $heute directly. Though it's unusual to have several gigs on one day (I guess, don't know the band ) $heute will return a page collection. Try either foreach($heute as $gigheute) { ... } and better rename them vars, or outputting $heute->first()->Datum. edit: Fixed typo

Thanks Ryan, looks this also comes in very handy to quickly setup a blog function.

Some brief feedback after using this module (V 3.1.3) on a project with PW 2.4. All in all a great tool for reducing page load times. There's an issue about this on Github and it will probably be addressed once the developer gets back from a trip but it took me a while to find so I'll mention that the cache ids are made from the modtime of the file(s). If you FTP files which arrive in the same second they will try to use the same cache file and your pages will be a mess. I suggested a fix. When using dev tools in browsers to inspect elements and peek into CSS files you'll be seeing the cache file filenames (md5 gibberish). I made a small modification to list the file path(s) at the top of the file. Sort of contrary to minifying but useful. EDIT: This idiom comes in handy to minimize only files in a certain folder. I do something just like it for 'styles' too. This way if I put URLs to external popular libraries (already minimized) in $config scripts they are left alone: foreach ($config->scripts->unique() as $path){ if(preg_match('#^'.$config->urls->templates.'scripts(.*)#',$path,$m)) $path = AIOM::JS('scripts'.$m[1]); echo ' <script type="text/javascript" src="'.$path.'"></script>'.PHP_EOL; }

Hello community My new website is nearly finished, I used: processwire (of course) dead simple grid modules: form Builder , XML SITEMAP

+1 ... and also to get better scores on WebPageTest page

Hi all, I have been looking for a way to manage deployment of new sites, as well as versioning of the pw data model on sites already deployed, working with teams, etc. I've enjoyed the discussion on a few threads : https://processwire.com/talk/topic/6707-update-live-site-from-staging-server https://processwire.com/talk/topic/2975-team-development https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes but so far, I have not found what I'm looking for, so I built two tools and have put them on my newbie github site for all to use and/or peruse. I hope they are relevant to this community. They are crude and only have been exercised in my relatively finite world of Windows/apache dev. See https://github.com/jeanrajotte/schlepwire and https://github.com/jeanrajotte/upgradewire Both "apps" are not designed to be modules, integrated into pw, but rather external simple apps serving their specific purposes, possibly usable in automated build systems via curl, for example. There's a bit of a diatribe in the upgradewire README.md about the goodness of keeping the model in version-able source files, as distinct from operating the pw admin to maintain fields and templates, even if these changes are being recorded, as mindplay.dk seems to be doing. That's really the philosophical thrust behind these efforts. It's a beginning. I hope it's of interest here. Again, thank you for this superb framework and this generous community. Jean

Shame I can't like myself.

As for your wish request. It is already possible to track changes, what -> old -> new value. $user->setTrackChanges(true); wire()->addHookAfter("User::changed", null, function($event){ $what = $event->arguments("what"); $old = $event->arguments("old"); $new = $event->arguments("new"); echo "changed: " . $what . " - " . $old . " -> " . $new; });

Short answer: do what your site/application requires and whatever is within the limit of your server's resources. My 2 cents: One question I always ask myself when dealing with session data is whether or not I want that data to reflect the same exact information that I saw while visiting the page the next time I visit. If I revisit the page after I log out, close the browser, or hit the back button, what should that data look like? Typically, if (other) users, applications, functions, methods, etc. need to modify this data, then a session variable is out of the question for me. But if I want this data to be the same after I enter it, (ie: shopping cart information that I have added a shirt to when at work that I want to review when I get home) then that information might be alright for me to use in a session. Nonetheless, I still prefer to store only enough information concerning the session. I usually reserve session variables to hold information (user name, id, department, specific date of something important - maybe sale end date, shirt item number, etc) directly related to the user, application, or page that is being served. Then, based on those parameters, I make Processwire fetch the needed page(s) information (cost of the shirt, quantity remaining, etc) because these things are subject to change.

Quick hint for translation: 1. Step use the ProcessLanguageTranslator https://github.com/kixe/ProcessLanguageTranslatorPlus/blob/master/README.md 2. Step with this Addon you could choose any "untranslated" file in a List including corefiles... best regards mr-fan

Brilliant; 3 days later i have full functionallity... login using ryan's script https://processwire....tor-login-form/ page edit using soma's modal trick https://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/ access control via http://modules.proce...-edit-per-user/ module and some cool table editing via profields table https://processwire.com/api/modules/profields/table/ 3 days with just a couple of hours a day..

upgrade.php is not a ProcessWire file. I'm guessing maybe it was a leftover from a previous WP or Joomla install? It sounds like it could be related to the exploit you experienced, but be careful not to assume it ends there. ProcessWire's core does not have very many input opportunities on the front-end of your site. Actually, the URL itself is really the only input ProcessWire deals with on the front-end, and that is validated by the htaccess before being sent to PW, and then thoroughly sanitized then validated again by the core. As a result, it's unlikely for ProcessWire itself to be exploited in the same ways that some other CMSs might be, simply because there are a lack of input opportunities to a guest visitor. What ProcessWire does instead is give you an API that lets you control all the aspects of when user input results in something output. If there were to be an exploit on a particular PW site, it would be much more likely to be the result of the code unique to that site, or a 3rd party module, rather than PW itself. If you were dealing with a site that had other software running, either presently or in the past (perhaps WP powering a blog alongside) then it'd be much more likely for that to be the source of the issue than PW. In fairness to WP, most exploits have to do with 3rd party WP plugins or themes and not WP itself. WP and Joomla are also much larger targets than PW, so they are usually broken into with automated scripts rather than actual people sitting at their computer. When you've got a site that you know has been broken into at the filesystem level (like yours might have been), it's unusual for it to be limited to just one file. There are usually backdoors built elsewhere. Even if the site is fixed for the moment, it's good to still think of everything as tainted until proven otherwise. I'm not necessarily a fan of restoring from a backup in this case, unless you know for certain that the backup itself does not contain the exploit. Sometimes a backdoor will be present for months before taken advantage of. If you had Joomla running on this server a long time ago, the exploit may have originated there and simply been hidden somewhere on the file system. The first thing you'd want to do is remove any other software installed on the server that doesn't need to be there–old copies of WP, Joomla, etc., or files leftover by them. If you aren't certain, then just move it to a non web accessible quarantine directory. For your ProcessWire site, you don't need anything in your web root directory except for: /wire/, /site/, /index.php and .htaccess. Remove your entire /wire/ directory and put in a new fresh copy, as well as your /index.php and /.htaccess file. Basically do the same thing you would do if performing an upgrade. In /site/modules/ you may have some 3rd party modules installed. Replace each of the directories in /site/modules/ with fresh copies. This is the same thing you'd do if upgrading those modules. That essentially leaves /site/ and everything in it to analyze. If the hack originated from an automated script targeting DrumlaPress, chances are it left your PW installation alone, but you never know–it might have gone after every single PHP and JS file it could find on the file system. You'll want to look for anything unusual in your /site/templates/*.php files and /site/config.php file. By unusual, I mean anything that you didn't put there. Start by looking at the beginning and ending of each file. Red flags are usually extra <script> statements, base64 function calls, exec function calls, extra JS attributes on markup elements that you didn't put there (like onclick), include or require statements with variable names in them or referencing files you don't recognize. Also consider that new directories may have been introduced anywhere. I would download a copy of your entire /site/ structure and analyze it locally, looking for any extra files or directories that you didn't put there. Also be on the lookout for extra .htaccess files, and give them a close look if you find any. Meaning, you'll need to make sure you are seeing hidden files (those preceded with a period). Compare your /site/ structure to a /site-default/ structure as included with a new copy of PW. Once you've cleaned your /site/ directory or at least verified that it's clean, make a good backup of your site so that you've got a known clean starting point (hopefully). Open a browser to your site with Chrome and go to View > Developer > Developer Tools. Click to the "Network" tab. Reload the page. Look for any offsite requests that you don't recognize. That may reveal something hidden that might still need to be cleaned, but hopefully not. Now click to the "Elements" tab. This shows the post-JS markup of your site. Look for any generated elements that you don't recognize, especially at the end or beginning. This again can reveal extras that have been added into your page by an exploit. Lastly (or maybe firstly?), take a look at your file permissions. If on a shared host, you want to be certain that your files aren't readable or writable to other users on the same server. Especially your /site/config.php file, and your /site/assets/ directory (and everything below). What permissions are ideal here depend on the web host and what type of PHP they are running, so it's best to inquire with them on how you can have files writable to your website that aren't writable by other accounts. Btw, I have never seen or heard of a compromised PW installation, regardless of what other compromised software was running on the server. I have seen plenty of compromised WP installations that had PW running alongside them. Thankfully, the PW installation has always been left alone, with the exploit limited to the WP installation. But it's best to go into these things assuming everything on the server is tainted, so always play it safe.

Here's a fun recipe... Install https://play.google.com/store/apps/details?id=eu.apksoft.android.smsgateway on an old android phone with a cheap sim with plenty of free sms messages. Expose the phone's webserver using https://pagekite.net/ (might be a bit of a challenge) (PageKite has been mentioned here before. Thanks Marty!) Send sms messages to your heart's content.

You have to build a small module, which hooks into the ___buildForm() function of the ProcessEditPage module. There you can add a cancel link, which maybe just points to the page-tree.

The trick with counters is to remove yourself from skewing the count. I find that when writing blog posts I load the page several times and this would increase the count several times. You could go a step further with diogo's code and do this to exclude your account (superuser) from increasing the count: if (!$user->isSuperuser()) { $page->counter += 1; $page->of(false); $page->save('counter'); $page->of(true); } echo $page->counter; Or you could do the same for multiple roles if you have different editors for your site (my example has some fake ones named "news" and "sports" below): if (!$user->hasRole('news') && !$user->hasRole('sports')) { $page->counter += 1; $page->of(false); $page->save('counter'); $page->of(true); } echo $page->counter; Just a thought