Leaderboard

This module facilitates quick batch creation (titles only or CSV import for other fields), editing, sorting, deletion, and CSV export of all children under a given page. You can even provide an alternate parent page which allows for editing of an external page tree. http://modules.processwire.com/modules/batch-child-editor/ https://github.com/adrianbj/BatchChildEditor The interface can be added to the Children Tab, or in a new dedicated tab, or placed inline with other fields in the Content tab. Various modes allow you to: Lister - Embeds a customized Lister interface. Installation of ListerPro will allow inline ajax editing of displayed fields. Edit - This allows you to rename existing child pages and add new child pages. It is non-destructive and so could be used on child pages that have their own children or other content fields (not just title). It includes the ability to quickly sort and delete pages and change page templates. Also allows full editing of each page via a modal dialog by clicking on the page name link. This is my preferred default setup - see how it replaces the default Children/Subpages with an easily addable/editable/sortable/renamable/deletable list. Note that the edit links open each child page in a modal for quick editing of all fields. Add - adds newly entered page titles as child pages to the list of existing siblings. You could create a list of pages in Word or whatever and just paste them in here and viola! This screenshot shows the editor in its own tab (name is configurable) and shows some of the CSV creation options. Update and Replace modes look fairly similar but show existing page titles. Update - Updates the titles (and any other fields if you enter CSV data) for the existing pages and adds any additionally entered pages. Replace - Works similarly to Add, but replaces all the existing children. There are checks that prevent this method working if there are any child pages with their own children or other content fields that are not empty. This check can be disabled in the module config settings, but please be very careful with this. Export to CSV - Generates a CSV file containing the fields for all child pages. Fields to be exported can to fixed or customizable by the user. Also includes an API export method. Populating fields on new pages In Add, Update, and Replace modes you can enter CSV formatted rows to populate all text/numeric fields, making for an extremely quick way of creating new pages and populating their content fields. Predefined Field Pairings Like the field connections setup from Ryan's CSV Importer, but defined ahead of time so the dev controls what columns from the CSV pair with which PW fields. This is especially powerful in Update mode giving editors the ability to periodically import a CSV file to update only certain fields on a entire set of child pages. These pairings also allow for importing fieldtypes with subfields - verified to work for Profields Textareas and MapMarker fields, but I think should work for most others as well - let me know if you find any that don't work. Access permission This module requires a new permission: "batch-child-editor". This permission is created automatically on install and is added to the superuser role, but it is up to the developer to add the permission to other roles as required. Config Settings This module is HIGHLY configurable down to setting up custom descriptions and notes for your editors. You define one config globally for the site and then optionally you can define completely custom configurations for each page tree parent on your site. There are too many settings to bother showing here - you really just need to look through all the options and play around with them!

Hello everyone! While there was couple of tryouts at the moment, I think PW was lacking decent HTML5 Boilerplate integration so here's a attempt to fix that. HTML5 Boilerplate for ProcessWire I took default install dump and stripped it down to bare minimum so it only includes data for Home and 404 pages + Title and Body fields. https://github.com/BlowbackDesign/PW-H5BP/blob/master/site-default/install/install.sql Default templates folder is modified so that head.inc and foot.inc contain basic HTML5-structure from H5BP and new 404.php is added for 404 page so that it matches H5BPs 404.html page (new redesigned version). Indents are switched from spaces to tabs and all elements are self closed - mostly out of personal preference. https://github.com/BlowbackDesign/PW-H5BP/tree/master/site-default/templates PW-H5BP is based on current master branch so it's little ahead of v4.3.0. Idea is to keep PW-H5BP up to date with releases of HTML5 Boilerplate.

@rusjoan: that error message is a bit vague, but it means that the name of your module is invalid. This is where it originates from. ProcessWire expects each module name to start with single letter (uppercase or lowercase), followed by one or more lowercase letters. Result of this is that "VkAPI", "Vkapi", "vkapi", "RusjoanVKAPI" etc. are valid names, while "VKAPI" is not. I'd suggest renaming your module to comply with that requirement, as that's the easiest solution here. Edit: for the record, I just submitted a pull request about adding a more descriptive error message.

Hey, I finally finished a lot of changes on my personal website like responsive, an about site, a better reference page, ... and of course an update to PW 2.4 Check it out: http://nico.is / Nico

On a slightly related note, I've found clients to be quite happy with "I don't know, I'll find out and get back to you", but if they've got an issue and can't reach anyone at your side, they won't be happy at all. Be clear about when you're available and stick to that. The absolute worst thing you can do is making promises and setting expectations you won't be able to fulfil. An easy way to increase customer satisfaction is exceeding expectations.. and the trick to exceeding expectations is setting them at a realistic level in the first place

You can set the description to have multiple row. Rather than just one input it will be a textarea. You could even use markdown or something and use textformatter on output. I would go for page per image.

Would you like to export it as a site profile for ease of installation? All you have to do is install the Profile Exporter module to create a profile from your setup and then people can install ProcessWire using this profile.

I know IPB (this forum software) has an archive feature, but it's only worth it for forums when you reach many thousands of posts and want to archive some stuff that you don't want to search. I just did a whildcard search on the forum database for these forums over the 59,000 posts and it took 0.2973 seconds! Add on maybe a second or two when we get to 590,000 posts and it's still not that big an issue (though I would consider Sphinx or something by that point). For large numbers of invoices/bookings/whatever if you simply use sensible selectors in your templates then there isn't really an upper limit aside from disk space. For example, only returning small result sets (25 or 50) and paginating, or offering filters to specify date ranges etc. You will very rarely want to return thousands of results in one massive list, and even if you did you certainly wouldn't want tens of thousands, let alone millions, so you're very unlikely to ever try and pull in every row of a database into memory - you're more likely to want to filter your results to find something. If your tables are properly indexed (I think in PW the equivalent is that your fields would be autojoin ) then hundreds of thousands of rows are just taking up space, not slowing down queries significantly. Now, when you get to queries where you want to search the body field which contains unknown content length for a specific word and you have millions of rows, then yes - that will probably take a lot of time. If you want to do things like that then something like Apache Lucence or Sphinx will be the option to go for. I wouldn't worry about it too much though to begin with. I used to get into a habit of thinking "what if my site reaches this size" and you generally find that you don't have to worry about it for several years or more, by which time there will be other technology or improved technology available to help you out (the next Lucence or Sphinx for example). So if you implement a solution on day one of your site/application but don't need to worry about such volume in your database until year 2+ you'll probably only have to update your code anyway to make use of newer technology

@Martijn: To install it under my windows apache I struggled over 2 days to find a php Imagick extension and the right ImageMagick installation that all together works with my PHP Version. It took me 3 hours Following is what I have found to work finally. Martijn, you will do this for the Mac when you have solved it, right? You first need to check if you are running a x86 (32bit) Apache / PHP or really a x64 bit one. I'm not sure but most installations on Windows maybe x86 (regardless if you running a x64 windows). I have taken a Imagick extension from here: http://www.peewit.fr/imagick/ I'm running PHP 5.4.26 as apache module and it is a ThreadSafe version what needs to be compiled with MSVC 9 The ImageMagick app is from here: http://imagemagick.org/script/binary-releases.php#windows I took the ImageMagick-6.8.9-0-Q16-x86-dll.exe it is for Win32 (x86), it should be a dynamic version (no static one) and we want 16bit pixel support If you work with other versions of Apache and PHP (e.g. x64) you need to choose x64 versions (MSVC 11 compiled) of ImageMagick / Imagick My Apache and PHP was already running so I installed ImageMagick with their provided Installer. The only important part was to tipp the checkbox that ask you to put the path from ImageMagick into your system-path variable! Second I copied the php_imagick.dll into the php extensions directory (look into php.ini at extension_dir = ) and add a line into the php.ini under Dynamic Extensions: extension=php_imagick.dll After restarting the Apache service I could see Imagick in the list of phpinfo(). Check this and also if you have a number higher than 0 for supported fileformats / imageformats in that phpinfo section. (with my first try installing ImageMagick I got versions that doesn't colaborate together what results in 0 supported fileformats there)

Good morning Ah, the existing image picker button in tinymce and the image manager module could provide those different sizes as well. Like the image manager a lot even that I didn´t tried it myself yet OT: I´m in the south of spain, cycling around the world with my girlfriend. If you´re interested, our blog is at www.globetrawter.tumblr.com Sometimes I would love when I were able to do something like this myself, but at the moment it´s not really appropriate to learn php and stuff^^ EDIT: As i mentioned before I´m not a PHP pro. How is it possible to check if an image is already inserted in tinymce or not? I think it would be great to have for example 1 thumbnail field. Throw all images in there. Pick those you want to show in the textarea (as in my post before, drag and drop the size) and leave all other images alone. All images left will be rendered as a little gallery below the text (or of course somewhere else) If needed you could even add a checkbox either to render the gallery or not (that´s the easiest part I know). The backend could highlight the images in the thumbnail field differently for those used in the RTE to have it even more fancy ;-)

PW Images Manager (beta) Just a weird little screencast trying to show how it works. (out of date a little, tags now use a textfield for easy copy/paste) This module allows you to manage images from one central repository. You create a root page "/images/" where you can then add categories and images as pages. From there the new admin page created "ImagesManager" will show categories and images added in a ajax data table, from where you can see and search/filter all images, upload and create new categories and edit images too. Every image will also show an image tag generated to copy into a textarea. This tag looks like this: {image=/path/to/image/imagename/, width=200}The width=100 is the thumbnail size used to output the image.You can also have additional segment to contain classes: {image=/path/to/image/imagename/, width=100, class=align_left}Or you can enter the id directly: {image=1033, width=100}Once inserted into a textarea field it will get parsed when saved and loaded automaticly. It will store an abstract id tag in Database and convert it back to the image HTML tag. So after first save you'll see the image inserted in a Wysiwyg and be able to resize and place it as usual. Once it's inserted somewhere Images Manager will show a search link with the pages containing the image (you can configure the fields int the module setting). You can change the image or move it to a different category, it will still work and show the correct image. This also works with multi-language fields.You can still also use the regular insert image dialog in TinyMCE and chose image from those pages. And it will start keeping track of those as well (they're the same after all). You can use those central images pages also with page fields to reference them single or even whole categories, search them with API and do what you like. Images Manager will also parse the page render on front-end and replace any found image tags with the HTML code. It will also look for a description on the image and output it as alt tag. If you want to have multi-language description you can add a `image_description` TextLanguage field to the image page template and have images parser use them. Along with this module, you can also install the `PageListImageLabel` module to add thumbnails to the image pages in the tree. To get it working you need to have the basic setup: 1. Create new `image` field with input setting to 1 max image 2. Create new `image` template and add `title` and the `image` field created before 3. Create a 'image-category' template with only title and allow the `image` template and `image-category` as child pages under family settings. 4. Create a `image-root` template with only the title field for the root of the images tree. Allow only `image-category` as child page under family settings. 5. Create the root page with the `image-root` under the home page as "/images/" 6. Done. The structure of the image repository looks like this /images/ /cagetory1/ /imagesxy/ /category2/ /image2/ /image3/ Now you can use the ImagesManager to add categories and images. But you can also still use the page tree to add new stuff as usual. The root path, template names and fields are configurable in the module settings. How to install the module: - Download the contents of this repository and put the folder renamed as "ImagesManager" into your site/modules/ folder - Login in to ProcessWire and got to Modules page and click "Check for new modules". You should see a note that the two new module were found. Install the "ImagesManager" module. - A new admin page "ImagesManager" should appear in the top menu. - You may configure the option on the module screen to suit your needs. Download at github https://github.com/somatonic/ImagesManager Thanks and enjoy.

Install Process Why not try to create a database automatically if it does not exist? When I entered HTTP Host Names and the DB Auth failed, I had to enter this information again. Please do not delete data in input fields if something was entered incorrectly. Adding fields When I add a field, I want to add it directly to one or more templates. This is solved very cumbersome. It would be better if I get a list of all templates and select in which templates the field should be added. Deleting fields "This field can not be deleted because it is used by one or more template ( s ) ." It should be displayed, in which templates the field is used. New Option: Force delete field There should be an option to force delete a field. "The field $fieldname is going to be removed from the following templates a b c Are you sure to delete it? (yes)(no)" New Option: Force delete template This Template is used by 3 pages: Page 1 Page 2 Page 3 Are you sure to delete it? (yes)(no)" What should happen with pages that have this template currently assigned after removal? ( ) Delete them too (X) Assign a new template Creating new templates When i created a new template with template->new from the dropdown-menu i don´t want to get back to the overview page for templates. I want to edit my newly created template directly. So please redirect to the edit page instead. This is a different behavior to adding fields, which works as intended. What was that fieldname again? Please show the name of the field after the label if debug mode is on (or always?) Easier select field The option/label should be only divided by = If no label is assigned, display the option as label What do you think of these improvements?

Hi apeisa, for a hobby horse project of mine - and to learn writing modules - I took the liberty to adapt your module for GitHub registration/login: https://github.com/marcus-herrmann/ProcessWire-GitHubLoginModule GitHub is using OAuth as well, so I had to more or less modify the URLs (and for some reason, giving a stream context to file_get_contents). Disclaimer: untested so far! Proof of concept.

Thanks Adrian, several use cases I can think of to use this one !

Yes, I would go for page per image with a specific template too. Partly because this gives the freedom of adding all kinds of information, but also in the template you can extract the image meta that the photographer will have as part of his images by default and use it for things like page metadata or simply for display purposes. Somewhere, in the depths of time I had a baby PHP script that pulled all that data from an image - I would think there are loads kicking around.

Pete: I haven't had the opportunity (?) to deal with truly large databases myself, but I remember discussing this with someone more experienced a few years ago. They had built a system for local university and hospitals for managing medical research data (or something like that, the details are a bit hazy). I don't really know what that data was like (probably never asked), but according to him they started running into various performance issues at database level after just a few million rows of it. Indexes in general make searches fast and having results in memory makes them even faster, but there's always a limit on buffer size, searching huge index takes time too and in some rare cases indexes can actually even make things worse. (Luckily the Optimizer is usually smart enough to identify the best approach to each specific scenario.) Downside of indexes is that they too take space and need to be updated when data changes -- they're not a silver bullet that makes all performance issues vanish, but can actually add to the issue. This also means that you'll need to consider the amount of inserts/updates vs. searches when creating your indexes, not just the fields to index and their order. This is starting to get almost theoretic and you're probably right that none of it matters to any of us here anyway (although what do I know, someone here might just be building the next Google, Craigslist or PayPal) -- just wanted to point out that it's not quite that simple when it comes to really large amounts of data. And no matter what you claim, (database) size does matter Edit: just saw your edits, apparently we're pretty much on the same page here after all

EDIT: I edited my posts because millions of rows will slow down a search, but you have to ask yourself when you expect to encounter millions of rows in your database? Comments on a news site maybe, but then when are you ever going to want to search the contents of a comments field across all articles? It's all relative to what your scenario is.

@Pete: actually archiving database content elsewhere could have it's merits, in some cases. Imagine a huge and constantly changing database of invoices, classifieds, messages, history data etc. Perhaps not the best possible examples, but anyway something that can grow into vast mass. Unless you keep adding extra muscle to the machine running your database (in which case there would only be theoretical limits to worry about), operations could become unbearably slow in the long run. To avoid that you could decide not to keep records older than, say, two years, in your production database. In case that you don't actually want to completely destroy old records, you'd need a way to move them aside (or archive them) in a way that enables you to later fetch something (doesn't have to be easy, though). Admittedly not the most common use case, but not entirely unimaginable either As for the solution, there are quite a few possibilities. In addition to deleting pages periodically you could do one or more of these: exporting pages via API into CSV or XML file(s) duplicating existing tables for local "snapshots" performing regular SQL dumps (typically exporting content into .sql files) using pages to store data from other pages in large chunks of CSV/JSON (or custom fieldtype per Pete's idea) In any case all of this isn't really going to be an issue before you've got a lot of data, and by lot I mean millions of pages, even. Like Pete said, caching methods, either built-in ones or ProCache, will make typical sites very slick even with huge amounts of content. If your content structure is static (unchanged, new fields added and old ones removed or renamed very rarely), custom fieldtype is a good option, and so is a custom database table. These depend on the kind of content you're storing and the features of the service you're building.

That is creative - nice.

Thoroughly enjoying that site - it does remind me of some silly requests I have had in sound studios over the years. * "Can we have the sound of headlights sweeping across a window?" * "I need a background atmosphere of two people sitting on a sofa." To which I replied, "doing what?" * "Can we lower the first violins slightly?" The radio producer/client asked me after I had played back a recently discovered, unbelievably rare mono recording of Dmitri Shostakovich conducting one of his OWN works in Moscow when he was young. The recording had been brought to me by a friend who was acting as an archivist for a library of recordings that had been kept hidden away by the Soviets. He thought it would suit this programme. "I cant lower the strings in an already mixed recording," I pointed out. "And anyway, even if I could, I don't think it would be right to do so." "Trust me," said the vain producer. "I know a lot more about Shostakovich than who ever that idiot is who is conducting!"

I'm confused, why are carts pages? The way I usually think of carts is something that would be a session variable specific to a user browsing your site, not a permanent fixture in your page tree. I'm not sure storing user carts in this way would be a sustainable. Carts are something that you'd usually want to store in a session or cookie, and not convert it to any permanent server-side storage until it's a completed order that you have to fulfill.

I agree with Pete that it'd be good to use different templates for your different types of products, as this fits the definition of a template. But if this is going to lead you to creating dozens of very similar templates, then I'd be less enthusiastic about that. If that's the case you may want to delegate your product options to a tree of page references (using PageListSelectMultiple inputfield maybe). If the options are very simple, you could always just identify them with each product in a textarea field (one per line). Textarea fields can be quite useful, as you can explode("\n", $page->textareaField) to convert it to an array and generate select options/radio buttons, etc. But you'd only take this path if the options were generally unique per product.

I think different templates is a good option here. If you create the basic "product" template, you can then go to edit it, click the Advanced tab and use the Duplicate/Clone option to copy it, then add the additional fields you require.

I think I understand the request, but feel this probably belongs as a module since it such a specific need. My opinion has always been that the core should only have features that would be regularly used in at least 30% of installations. Otherwise we run the risk of having too much, over-configuration, etc. There are actually some modules we now have in the core that aren't used in at least 30% of installations (anyone ever used FieldtypeCache or some of the lesser known Textformatter modules we include?), so these will likely be moved out of the core in an upcoming version of PW. When it comes to meeting specific needs, I prefer to update the core to add new hooks where necessary (for modules) rather than adding new functionality or configuration. I think your case is one that does sound like a useful capability, but I'd prefer to assist you in implementing it as a module rather than adding it to the core. I'm sure some others will find it useful too, so would like to see it in the modules directory too.

I have written a little module that extends Somas awesome Images Manager. Also it's written with Somas kind help, (thanks!) It adds auto filling of EXIF or IPTC fields where available on upload of new images through Images Manager. How to use it: You, of course have Images Manager installed and ready to run. Now you have to create some fields that should take your exif data: fieldname prefix is exif_ followed by the original exif-fieldname but lowercase! ( exif_author, exif_copyright, etc.) ALSO you have to create one TextArea field called (by default) image_exif, - this one and ... (not needed, only optional to get the full raw EXIF-data stored) all your exif_fields you have to add to the image-template that is used by Images Manager for creating the new Image Pages. then download and install the ImagesManagerMetadata module. here are a little screencast I've done with it: https://youtu.be/wjhJdT7Tf5Y this is alpha, version 0.0.2 ImagesManagerMetadata.zip