Joss

AHHHHH.... Run for the Hills!!! Rebel!!!

Clue:

The reason that, for instance, there is no gallery module as part of the default offering is several fold: What gallery functionality would be offered? What fields would it use and what would they be called? What JQuery plugin would it use? (Or Mootools, or something else?) Who would maintain that plugin? What markup would it use? Would it be usable within a framework like Bootstrap? And so on. One of the main reasons I eventually dumped Joomla entirely is that I got fed up trawling through gallery or similar plugins and never being able to find one that did precisely what I wanted. And because they were trying to be everything to everyone, they were hugely bigger than the basic bit of JQuery they were initially based on. On top of that, they broke every time Joomla turned left at update, were often full of bugs or left gaping security holes, did not have enough staff to support them and then the devs went and charged for the wretched things. ProcessWire for me as a non-developer, means I can tailor make my sites exactly as I want them with no compromise and only have myself to blame if it goes wrong. But that does not mean that third party developers cannot, working independently, create exactly what you are talking about - if you dig through the forums there is already a blog module that is very feature rich and there is also basic shop functionality developed by users. But it is not practicable to expect the core developer (one clever chappy called Ryan) to add to his todo list and then support.

I think this is the problem, the catering bit. PW is a one man company with a small group of talented and helpful contributors. The current situation is that there is just enough people to manage and support PW as it is. If it grew a complex layer on top of the existing system that would need to be monitored, continually updated and so on, then it would quickly become unmanageable. One of the reasons that there are so many CMS type system out there full of bugs (especially plugins) and have huge maintenance issues is because they grew beyond the ability of the original developers to control and maintain properly. In that way, growth does not add value, indeed it can undermine it. As several of us have said, the profile system allows for variants to be created that can be installed as part of the main installation. So, if some users want to create a profile that offers the same sort of plug and play features as WordPress or Joomla, then that is by far the better way to do it than to expect the core maintainers to do it and in the process risk the integrity and maintainability of the system as it stands now. Really, this is nothing to do with what CAN be added to ProcessWire in the way of additional functionality - we all know that anything is possible - really this is about WHO adds all that functionality and who has the time to maintain it properly: if even just a thousand people use that sort of system and want support, then that is a full time job on its own.

@argos Here is a prezzie for you: How to create a gallery without getting bogged down by someone else's module: https://processwire.com/docs/tutorials/galleries-short-and-long/ Brand new, I just wrote it while drinking my coffee.

Yep, but there are others out there like colorbox

Er ... at least I am working on that. .... Cough!

Yep, worked out, though I haven't the foggiest why a php error would affect just one little bit of jquery functionality. A mystery it will have to remain, however, as I have already spent way too much time on it!

One thing that is getting missed in this conversation is people like me. Anyone who reads my signiture might notice it says: Be nice - I am not a proper programmer and haven't the foggiest idea of what Soma/Apeisa/Ryan/et al are talking about. The point is that when I started my php knowledge was very, very, very minimal. I understood what it did, but I didn't know how to use it beyond the basics. It is not a hell of a lot better now, but it is better. The reason is that PW is a very good platform on which to LEARN php, and jquery and, of course, the PW API. So much so that one day I will create a profile that is expressly a tutorial profile - in other words, it will teach php to complete novices as well as teaching PW. ProcessWire is a developer tool - there is no getting away from that - and it requires a developers approach to use it. But, as I and others have proved to themselves, it does not shut out non-developers and can actually turn novices and others into devs. This is partly because of the design logic built in by Ryan and partly because of the community. But, despite that, despite the fact that an old composer/writer/advertising bloke like me can create websites, it is not any use for those with no knowledge at all who want a quick site without having to get any knowledge. They are better off using Wordpress.com or the plenty of other plug and play, ready hosted offerings - that is what they exist for.

Yes - the php.net examples drive me nuts, especially the ones that turn out to be plain wrong! grrr! (Mind you, if I actually knew php properly, then this would be less of a problem.... )

Okay, solved it. But something must have changed in Dev that I have missed. Basically, I forgot to check if the image existed before outputting it. (Embarrassing since I make a big thing about that on my tutorials!) Normally, this would scream a huge great error at you, but for some reason it didn't. Because the basic-page is rendering two child pages (currently) and the second one did not have an image, that threw a server error which impacted on the foundation aside code, though I really don't know how. Putting the check to make sure the field had an image in it solved the problem.

No markup issues - after all, it works fine without the width() command.

Yep, basically that. I am beginning to think this is a server error to do with the way I am grabbing just a part of the sub-page template that is doing something odd. So I need to eliminate that first.

Yes I have checked.

I personally would not welcome PW becoming as popular as WP, and there is no need for it to be so. It is not competing with the mass market appeal of wordpress as it is in a completely different market sector. Huge numbers of users does not equate to a good product, just an overused one. It is not possible to have commercial templates for PW as it has no templating system - how would you know what people call their fields? Do you want to tie people down to only one sort of field name/type/strategy? Do you want to restrict people on how they construct templates? Many of the devs in here do not use a header/footer type system. As soon as you introduce a templating layer (Like Joomla has, for instance) where if you want to do something completely different you have to bung in a ton of overrides, you now have a bulky, slow system again. The advantage of PW is that this is completely missing - this is a good thing. As for standards, everything is built on the API and PHP - that is ALL standards. Any professional can build modules quickly and easily, though for most things like galleries, dancing frogs, and the rest there is no need whatsoever. Why limit people to restrictive module systems when they can just go and grab ANY bit of JavaScript out there and simply drop it in? As I said before, if you want to use PW as a WP clone, then create a profile that has all that sort of functionality - but that is a different product, not PW itself.

@sforsman Yep.

Hi Video kid - that doesn't make any difference. I think close_on_click might be true on default, can't remember now. Reems - thanks! The animations are done in Adobe Edge Animate. The top one has the crane driver raising and lowering the phone (complete with the wheel turning, his arm moving etc) plus the forman guiding him, the dogs head moving and the chap carrying the bricks wobbling. The draftsman is drawing and the minstrel is tapping his foot, strumming the lute and shaking his head. I should probably compose some music for him. I think this has something to do with the way I am removing bits of code when rendering the template - I will look at a different approach.

Okay, though you might find it boring - as I said, they are almost identicle. The only bit that actually gets rendered is lines 69 to 83 ish <?php if ($page->url == $_SERVER["REQUEST_URI"]) { /** * basic-page template * Use this as the basis for any other template for this profile */ include("./includes/head.inc"); ?> <!-- Header Stuff --> <div class="pageheader"> <div class="row"> <div class="columns"> </div> </div> </div> <!-- Main Page Markup goes here --> <div class="wrapper-inside"><!-- Using a wrapper to give the main contents area a background colour --> <div class="row"> <!-- off canvas menu --> <div class="off-canvas-wrap" data-offcanvas> <div class="inner-wrap"> <nav class="tab-bar"> <section class="left-small"> <a class="left-off-canvas-toggle menu-icon" ><span></span></a> </section> <section class="middle tab-bar-section"> <a class="left-off-canvas-toggle"><h4 class="title">Menu</h4></a> </section> </nav> <!-- Off Canvas Menu --> <aside class="left-off-canvas-menu"> <!-- whatever you want goes here --> <?php // If this is a first level page, child of root, then we show its children if($page->parentID === 1){ childrensectionmenu(); } // if this is not a first level page, not a child of root, we show its siblings if($page->parentID !== 1){ currentsectionmenu(); } // Always show this bit of menu mainsectionmenu(); //include("./includes/navigationvert.inc"); ?> </aside> <!-- main content goes here --> <section class="main-section"> <?php } // End If for page URL ?> <div class="row"> <div class="medium-6 columns" id="<?php echo $page->name; ?>"> <h1><?php echo $page->title; ?></h1> <?php echo $page->body; ?> <p><a href="<?php echo $page->url; ?>">read more</a></p> </div> <div class="medium-6 columns"> <img src="<?php echo $page->main_image->width(400)->url; ?>" > </div> </div> <?php if ($page->url == $_SERVER["REQUEST_URI"]){ ?> </section> <!-- close the off-canvas menu --> <a class="exit-off-canvas"></a> </div><!-- /inner wrap --> </div><!-- /off-canvas-wrap --> <!-- end menu --> </div><!-- /row --> </div><!--/wrapper--> <!-- /End main page markup --> <?php /* Included common footer markup */ include("./includes/footer.inc"); ?> <!-- add any post footer specific to the page here --> <?php /* Included common <scripts> */ include("./includes/footscripts.inc"); ?> <!-- add any scripts like foundation plugins specific to this page here --> <!-- initialize foundation --> <script src="<?php echo $config->urls->templates?>js/foundation/foundation.offcanvas.js"></script> <script> $(document).foundation(); </script> <?php /* Wrapping up the page */ include("./includes/foot.inc"); } //end if for page URL

The dange is in making PW user-friendly for non-devs it suddenly becomes very unfriendly for developers. A major mistake we all make is comparing ProcessWire to AMS (Article management systems) like Wordpress and Joomla. The point is that ProcessWire, as presented on this site, is not that type of system - it is a content management framework that allows developers to build the CMS or AMS of their own design. Because of the profile system, it would be perfectly possible to build a WordPress clone on top of ProcessWire that would probably be faster and stronger than WordPress - but this would then be a different product "based" on ProcessWire and should have its own related identity, own support structure, own developers and so on. Likewise, I think Apesia's shop module could be expanded hugely into a full profile that again would warrant it's own site, support and so on. But these would not be the core framework that is ProcessWire and should be separate systems and not replace PW.

Morning world! The actual size of the image is not a problem. The original image is 500 wide and is simply pushed off the side of the div. Basically, there are two templates: sub-page is the proper template for the child page. It uses if ($page->url == $_SERVER["REQUEST_URI"]) { } to remove header and footer info for when the sub-page child is rendered into the parent page. The resize does not appear to be an issue when this page/template is called directly. basic-page is the parent template. The majority of this template is identical to sub-page, except that it loops through and renders the children. This is where the aside is suddenly not working. For amusement, here is the basic-page template. Not sure it means much out of context, to be honest! EDIT: By the way, I have tried removing all the code for what goes into the aside, and that makes no difference. <?php /** * basic-page template * Use this as the basis for any other template for this profile */ include("./includes/head.inc"); ?> <!-- Header Stuff --> <div class="pageheader"> <div class="row"> <div class="columns"> </div> </div> </div> <!-- Main Page Markup goes here --> <div class="wrapper-inside"><!-- Using a wrapper to give the main contents area a background colour --> <div class="row"> <!-- off canvas menu --> <div class="off-canvas-wrap" data-offcanvas> <div class="inner-wrap"> <nav class="tab-bar"> <section class="left-small"> <a class="left-off-canvas-toggle menu-icon" ><span></span></a> </section> <section class="middle tab-bar-section"> <a class="left-off-canvas-toggle"><h4 class="title">Menu</h4></a> </section> </nav> <!-- Off Canvas Menu --> <aside class="left-off-canvas-menu"> <!-- whatever you want goes here --> <?php // If this is a first level page, child of root, then we show its children if($page->parentID === 1){ childrensectionmenu(); } // if this is not a first level page, not a child of root, we show its siblings if($page->parentID !== 1){ currentsectionmenu(); } // Always show this bit of menu mainsectionmenu(); //include("./includes/navigationvert.inc"); ?> </aside> <!-- main content goes here --> <section class="main-section"> <div class="row"> <div class="medium-6 columns"> <h1><?php echo $page->title; ?></h1> <?php echo $page->body; ?> </div> <div class="medium-6 columns"> Something else </div> </div><!-- /row --> <?php if ($page->child) { $childsections = $page->children("limit=10"); foreach($childsections as $childsection){ echo $childsection->render(); } // end foreach $childsections } //end if $page->child ?> </section> <!-- close the off-canvas menu --> <a class="exit-off-canvas"></a> </div><!-- /inner wrap --> </div><!-- /off-canvas-wrap --> <!-- end menu --> </div><!-- /row --> </div><!--/wrapper--> <!-- /End main page markup --> <?php /* Included common footer markup */ include("./includes/footer.inc"); ?> <!-- add any post footer specific to the page here --> <?php /* Included common <scripts> */ include("./includes/footscripts.inc"); ?> <!-- add any scripts like foundation plugins specific to this page here --> <!-- initialize foundation --> <script src="<?php echo $config->urls->templates?>js/foundation/foundation.offcanvas.js"></script> <script> $(document).foundation({ offcanvas : { close_on_click : true, } }); </script> <?php /* Wrapping up the page */ include("./includes/foot.inc");

Er ... no idea. Do you mean hard link to myimage.400x0.jpg?

Thanks Martijn - just knocked it up for my new web design site (that I am losing sleep over) Here is a screen of the front page - all those are animations. I really am not an artist, but since I can't afford to employ one, I will have to do!

Okay, so I have no idea where to start with this one. Foundation 5 has an off-canvas menu system described here: http://foundation.zurb.com/docs/components/offcanvas.html I have a template that uses this function. It also calls in child pages and renders them down the page. So far, it works fine. Now, I add to the child template an image: <?php echo $page->main_image->url; ?> All good - renders fine, everything wonderful. Now, I resize it: <?php echo $page->main_image->width(400)->url; ?> The image is shown, it has been resized and every thing is wonderful, yes? Well, no - because the offcanvas menu no longer works! Revert to no resizing, it works fine, use any resize (height, width, size) it breaks. Er, why? The menu is a Jquery function, the resize is a php function. So, why are they conflicting? I must be getting old.....

Couple of bits of wording jump to mind. Perhaps: Instead of "the found version....." have: "The available version is the same as your current installation" Instead of "we recommend you make another backup on your own too...." Have: "For additional safety, we recommend creating an independant database backup, for instance with PhpMyAdmin" Good tool though!

I am currently fighting with an e-commerce site that the client wants on WordPress. I think I am in genuine pain! Using woocommerce, which does offer the client what he needs (product with selectable digital download or physical cd) and simple management. But where I am losing sleep is over WordPress itself. Trying to customize how things are displayed and ordered is a minefield and the amount of included bits of stylesheets, scripts and so on is a mess. Though interestingly, the developer of Mega Slider (which I am using) has now had a little peak at dear ProcesssWire and is intrigued by it. Although it will be too late for this project, I would happily throw some time into taking the current shop module for PW and take it to its ultimate conclusion! I personally think that none of the currently available carts out there (Open Source or otherwise) are even remotely developer friendly. When you think about it, there is nothing very complicated about an online shop. It is simply displaying and collecting data - so why have all these projects become like swimming in glue?