Leaderboard

A new project, we are working on at updateAG, is now online (at least first step, online "reservation" process isn't yet) http://www.walder.ch The data for the shoes are imported from their system va CSV. They then can edit and publish and categorize them as they wish. Soon there will come a reservation process, that's only half implemented yet. It's an ongoing process in all parts and will get reworked or extended by time. They were using Typo3 before and were positively surprized and happy with ProcessWire and think it's all a lot simpler. They can edit all their content only with a rough 15 min crash course "showing" them ProcessWire. Design and concept is from another partner firm, who also executes the print campaigns for the client. Maybe something special to mention: is that we fighted a lot with their product fotos. The plan was to use transparent png's and then so be able to color the background. This lead to a lot of problems with png's and GDlib in general. Plus they delivered the fotos as optimized png's 8bit... etc. Very long story short. With the excellent PIA (PageImageManipulator by horst) and after lot of researching and testing I was finally able to "color a canvas", smash the png on it and have a jpg coming out on the other end! This way, we solved a lot of problems with a simple command and have regained back a lot of flexiblity, lesser artifacts and 10times lesser file sizes at the end.

No offense to any of you, but did you look at how small pwFoo's system's basic building blocks are: https://bitbucket.org/pwFoo/formhelper/src/21693e79e771b85c236124e523c972a805fb44e1/FormHelper/FormHelper.module?at=master&fileviewer=file-view-default https://bitbucket.org/pwFoo/frontenduser/src/71207f581585ac6e089b47790eadbf3bdbedd5a9/FrontendUser/FrontendUser.module?at=master&fileviewer=file-view-default If "possibility of abandoning" means "possibility of breaking with API changes", 1. PW API breaks very rarely 2. pwFoo's codebase is really small and anyone depending on it could fix breakage, if push comes to shove

^ That's the same module I linked to But yes Beluga, you're right and that's what I would say too - the API isn't going to fundamentally change any time soon so the majority of frontend development like this module shouldn't be affected by upgrades most of the time. I would say actually admin modules have a little more chance of being affected by upgrades when larger new features are added to PW, but that's why you have to make the decision for yourself which branch you download from Github for your sites. You also have to balance this with the other responsibilities of being a web developer/admin - any updates should theoretically be checked by yourself on a non-live copy to see what the impact will be on the modules/templates you're using. This is best practice, however it doesn't always happen (I know I'm guilty of throwing caution to the wind with my personal sites anyway ). And of course when modules aren't updated or code breaks, there's a forum full of folks here to help out. I think in the absolute worst case scenario, if a module you like doesn't get updated for compatibility with newer versions of ProcessWire, you don't actually have to upgrade ProcessWire itself on the affected site. I know that, unlike any other CMS I've used, my sites are all on varying versions of ProcessWire and ticking along quite nicely which is nice.

And another brick to the wall: setting column header checkboxes based on column items. If all items checked (or marked for deletion), the "check all" column checkbox gets checked. State is also set on loading BCE.

I would use permissions or take a shurtcut and use roles for that. The shortest route is to use user, but I think it is messy even in your situation, since you have at least two users that can see the content ("user X or Y"). - So first create (and publish) new permission, lets call it "view-hidden" - Create new role (or use existing role) and add the new permission to all roles that should be able to view hidden content - Now make sure that user X and Y have roles that have "view-hidden" permission Then on your template code: if ($user->hasPermission("view-hidden")) { echo "This is hidden content block"; } If you took the shortcut with using roles directly, then it would be: if ($user->hasRole("admin")) { echo "This is hidden content block"; }

isnot would be expressed by the false of is if(!$page->is("template=foo|bar"))

Two important updates: initializing the lightbox on click instead of document ready: this allows DOM manipulation and keeping functionality (eg. when appending or cloning the item elsewhere in the document) multilanguage-aware helper function: tabs of the active language are opened by default (see examples on GitHub). This is really handy because it is easy to mix up languages even for me not to mention the clients Unfortunately the built-in editUrl() doesn't seem to provide this feature but appending "&language=LANG_ID" did the trick. No more messing with language tabs

You're mixing vanilla PHP with PW API. Selectors are PW specific. I don't know you guys know that you can also do this in PW (usually people miss this) if($page->is("template=home|basic-page")) echo "has template";

Hi, FrontendUser base module is simple and small. It should be extended with sub modules and plugins based on PW hooks. I wrote it because there was no universal and extendable frontend login / register module. PW modules are optimized for backend usage (inputfields, login, ...). Would be great if the PW modules would also work in the frontend, but that isn't targeted / supported.

For example http://processwire.com/index.php/this/page/dont/exists should return a 404 error code.

Hi kixe! Here is the structure of my custom table: CREATE TABLE IF NOT EXISTS `t_fsk` ( `id_fsk` int(11) NOT NULL AUTO_INCREMENT, `f_fsk_value` int(11) NOT NULL, `f_fsk` varchar(200) NOT NULL, PRIMARY KEY (`id_fsk`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ; I used the field "f_fsk_value" (values are; 1,2,3,4,5,6) as "option value" and the field "f_fsk" as "option label". My selection will stored correctly into the database but when I try to edit the page a second time, the selection I made before isn't displayed. I tried the select and selectMulitple Option. Both of them with the same result. May you have an idea to solve this problem?

It took my a while to realize that this could be VERY educational, thank you BernhardB!

Hi, If your PHP setup is running in safe mode, you can only change values from the php.ini file. If the upload_max_filesize is larger than post_max_size, you must increase post_max_size so that it is bigger than upload_max_size. If the value of post_max_size is larger than memory_limit, you must increase memory_limit so that it is larger than post_max_size. Try increasing the following values in php.ini, for example: memory_limit = 32M upload_max_filesize = 24M post_max_size = 32M

I think $100 is a bit steep for something with this functionality but I would happily spend $30 in a heartbeat on it with a yearly support fee like Ryan's modules. If there was a developer here who was interested I bet some of us could band together and commit to purchasing the module so that the incentive was clear. And absolutely no offense to pwfoo at all, I think they would be a great dev to possibly take on the project if they were interested as they already have written a good portion to what I would imagine the final product would be. I would love a module that had front end user administration as a core to the module. Something that possibly even separated front end users from administrators and allowed for really slick integration with custom fields for front end users.

in your sites config.php you can set them like below. $config->imageSizerOptions = array( 'upscaling' => true, // upscale if necessary to reach target size? 'cropping' => true, // crop if necessary to reach target size? 'autoRotation' => true, // automatically correct orientation? 'sharpening' => 'none', // sharpening: none | soft | medium | strong 'quality' => 100, // quality: 1-100 where higher is better but bigger 'hidpiQuality' => 60, // Same as above quality setting, but specific to hidpi images 'defaultGamma' => -1, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) );

You could switch dependencies, where Pages2Pdf installs WirePDF, instead of requiring it to be installed previously.

I've already add this to github, as even the first option should be able to just download the thing without installing. https://github.com/ryancramerdesign/ProcessWire/issues/1387

No offense to the developer of FrontendUser, but I'm cautious about using modules that provide functionality that are core to a project's success. I came from the WordPress world and was burned more than once on plugins that were no longer supported by the developer. I'm at the point where I would rather spend $100 on a module and be confident that it is going to be supported rather than using a free module that may later be abandoned. Yes, basics like registration, login, change password, email address, name, and upload image would need to be supported, allowing users to edit their profile using a custom front end template without having access to PW's back end admin.

So I've updated mine - these are essential to my current projects: TemplateDataProviders TemplateTwigReplace MarkupSitemapXML Blick VersionControl (ProDrafts looks awesome, though) And, of course, for migrations: Jumplinks

If I may interject, here is an MW skin that uses Foundation: https://www.mediawiki.org/wiki/Skin:Foreground Only v4 though.. maybe they will go straight to v6 when it hits.

Not a problem, and glad it worked out for you. Sometimes the easy way is the way to go when you're on a tight timescale that can't be changed, even if you know there could be a better way. Web developers aren't supermen after all (with the exception of Ryan of course). What was the skin you used in the end, just out of curiosity? I don't really like the default one that ships with MediaWiki myself - feels a bit outdated.

Thanks bramwolf, yes it does help I had the usual thing happen: I worked it out after I'd posted but v.helpful to have it confirmed. Cheers!

Ok, you did more changes than only those two. I noticed that you changed from { to [[ and seems to me that you removed the ability to output all the images from the field. I also had trouble to output the images even after I changed the call to [[ and can't seem to figure out why. I guess I would need more time to test the module before merging and won't have much time during this week. Would you prefer to wait or release the module on your own? Any is fine for me

Correction. Applying always_populate_raw_post_data = -1 to the php.ini as a workaround do the job and enables image upload again.

You should use Fieldtypeoptions now which is built into the 2.6 branch - it is a core module that does the same and more

Hi @holmescreek and welcome to the forums. What you need to do is define a separate role - perhaps called "deletor" and give it edit and delete permissions. Now remove the delete permission from the main editor role. Now for the pages that you want the delete option to appear on, give their template edit permission for the deletor role. Something like this:

Get it from GitHub Setup Just put the module in you modules directory and install it via admin. Intro This module might come in handy if you like to keep your templates clean and free of unreadable and unmaintainable string concatenations and even free of any logic. It also comes with some handy features besides just embedding JS, CSS and image assets, see below. Yikes! <link href="<?php echo $config->urls->templates . 'styles/foo.css'; ?>"> <link href="<?php echo $config->urls->templates . 'styles/bar.css'; ?>"> <script src="<?php echo $config->urls->templates . 'scripts/foo.js'; ?>"></script> <script src="<?php echo $config->urls->templates . 'scripts/bar.js'; ?>"></script> <img src="<?php echo $config->urls->templates . 'images/sky-scraper.jpg'; ?>" alt="Some huge building"> <img src="<?php echo $config->urls->templates . 'images/owzim.jpg'; ?>" alt="Handsome!"> Way cleaner <?php echo $asset->css('foo'); ?> <?php echo $asset->js('foo'); ?> <?php echo $asset->img('sky-scraper.jpg', 'Some huge building'); ?> or with short syntax <?= $asset->css('bar') ?> <?= $asset->js('bar') ?> <?= $asset->img('owzim.jpg', 'Handsome!') ?> And prettier if you're using Twig {{ asset.css('foo') }} {{ asset.css('bar') }} {{ asset.js('foo') }} {{ asset.js('bar') }} {{ asset.img('sky-scraper.jpg', 'Some huge building') }} {{ asset.img('owzim.jpg', 'Handsome!') }} Usage JS example Let's use the js method an its configuration as an example, and assume we have the following files located in /site/templates/scripts - index.js - index.min.js - main.js $config->blick = array( 'jsPath' => $config->paths->templates . 'scripts', 'jsUrl' => $config->urls->templates . 'scripts', 'jsMarkup' => '<script src="{url}"></script>', 'jsDefault' => 'markup', 'jsVersioning' => true, 'jsVersioningFormat' => '?v={version}', 'jsMin' => true, 'jsMinFormat' => "{file}.min.{ext}", ); $asset = $modules->get('Blick'); $asset->js('index')->url; // returns /site/templates/scripts/index.min.js?v=1426170460935 // 'min' and version parameter added, which was fetched from the file modified date $asset->js('main')->url; // returns /site/templates/scripts/main.js?v=1426170460935 // without 'min', because there is no main.min.js $asset->js('main'); // returns <script src="/site/templates/scripts/main.js"></script> // because 'jsDefault' is set to 'markup' // you can also access it explicitly via $asset->js('main')->markup $asset->js('http://code.jquery.com/jquery-2.1.3.js'); // returns <script src="http://code.jquery.com/jquery-2.1.3.js"></script> // nothing is modified here, because it's a remote url You can use the file name with or without extension. Adding a version parameter only takes place, if jsVersioning is set to true, it's a local file and it exists. Modifying the file name to include min only takes place, if jsMin is set to true, it's a local file and it exists. The same applies for the $asset->css('file') method: $config->blick = array( 'cssPath' => $config->paths->templates . 'styles', 'cssUrl' => $config->urls->templates . 'styles', // and so on ... ); IMG example the img method lets you include images, crop and resize them, without them having to be a page image. $config->blick = array( 'imgPath' => $config->paths->templates . 'images', 'imgUrl' => $config->urls->templates . 'images', 'imgMarkup' => '<img {attrs} src="{url}" alt="{0}">', 'imgDefault' => 'markup', 'imgVariationSubDir' => 'variations', ); $asset = $modules->get('Blick'); $asset->img('sky-scraper.jpg')->url; // returns /site/templates/images/sky-scraper.jpg $asset->img('sky-scraper.jpg', 'Some huge building'); // returns <img src="/site/templates/images/sky-scraper.jpg" alt="Some huge building"> // any arguments following the filename are passed as an array // in this case the alt value is the 0th argument, so {0} get's replaced // you can set as many arguments as you want in 'imgMarkup' $asset->img('sky-scraper.jpg')->size(100, 100)->url; // returns /site/templates/images/variations/sky-scraper.100x100.jpg // the resized image is put into a subdir 'variations' as configured in 'imgVariationSubDir' // if 'imgVariationSubDir' is left empty, the variation will be put in the same directory $asset->img('sky-scraper.jpg', 'Some huge building')->attr('title', 'Some huge building'); // returns <img title="Some huge building" src="/site/templates/images/sky-scraper.jpg" alt="Some huge building"> // the resized image is put into a subdir 'variations' as configured in 'imgVariationSubDir' // if 'imgVariationSubDir' is left empty, the variation will be put in the same directory You can also setup predefined variation settings in imgVariations $config->blick = array( 'imgVariations' => array( 'header' => array( 'width' => 960, 'height' => 360, 'options' => array( 'suffix' => 'header', ), ), 'person' => array( // and so on ... ), ), ); And call it like so: $asset->img('sky-scraper.jpg')->variant('header')->url; // returns /site/templates/images/variations/sky-scraper.960x360-header.jpg $asset->img('sky-scraper.jpg')->variant('header', 50)->url; // returns /site/templates/images/variations/sky-scraper.480x180-header.jpg Attributes example Since version 0.4.0 you don't need to create arbitrary variable placeholders, if you want to use attributes only. Now you can use the {attrs} placeholder and set the attributes via $asset->attr('name', 'value'). The name argument can also be multiple names, split by a pipe |. $config->blick = array( // ... 'imgMarkup' => '<img {attrs} src="{url}">', // ... ); $asset->img('sky-scraper.jpg')->attr('alt|title', 'Some huge building'); // returns <img alt="Some huge building" title="Some huge building" src="/site/templates/images/sky-scraper.jpg" > Using files that are not in the configured directory If you want to include files, that are neither in the configured directory nor in one of its sub directores, just use an absolute path (actually, relative to your /site directory. $asset->js($config->urls->SomeModule . 'scripts/file-in-root'); Autoload the module If you don't want to include the module manually via $assets = $modules->get('Blick'); you can set it to be autoloaded under a custom name: $config->blick['autoloadAs'] = 'fiddle'; Now it becomes automatically available in your templates under the name fiddle $fiddle->css('foo'); $fiddle->js('foo'); $fiddle->img('baz.png', 'qux'); Please note, that, if you're using the TemplateTwigReplace.module you will have to add your chosen autoload name to the Auto-import fuel list on the module's config page. See config-example.php for all configurable settings. Change Log 0.5.0 add optional scale argument to variant-method: $asset->img('foo.jpg')->variant('header', 50) 0.4.0 add possibility to get/set and render attributes (see section Attributes example) 0.3.0 add $asset->variant('name') alias for $asset->getVariation('name') 0.2.0 fixes and internal refactorings 0.1.0 initial version

There is now "options" fieldtype in core. You can use it instead.

$modules->uninstall("ModuleClassName");

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

The simple PHP OR comparison solution is very common. The in_array solution is more flexible. The PW solution owns them all =)