Leaderboard
Popular Content
Showing content with the highest reputation on 05/25/2015 in all areas
-
5 points
-
I found myself once in that picture... luckily for me I realized in time.3 points
-
2 points
-
The problem aren't people who actively turn off their javascript, but rather all the cases where it's execution breaks. Just be on a train with bad network, then you're happy if a page is "accessable" without js. No need to fully support all fancyness, but make the html base usable without js.2 points
-
In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.1 point
-
hi all, new PW site launch: http://www.ohmspeaker.com/ some of the modules that were helpful or essential for this: cropimage formbuilder fredi importcsv minify piwik analytics procache batcher redirects version control template decorator modules manager page link abstractor sitemap xml admin custom pages markup simple navigation (for the sitemap) forum topics related to this site dev: Legacy Site URL redirects: http://processwire.com/talk/topic/3641-redirect-legacy-url-to-new-pw-page/ Clean up spelling: http://processwire.com/talk/topic/3519-use-api-to-spellcheck-whole-siteclean-up-spacing/ hashes in URLs on change selected product http://processwire.com/talk/topic/3496-help-with-url-param-change/ FormBuilder http://processwire.com/talk/topic/2904-how-to-redirect-by-id/ http://processwire.com/talk/topic/2821-3rd-party-send-conditionally/ http://processwire.com/talk/topic/2820-use-session-to-remember-form-selections/ Custom Menus http://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/ other notes: The skyscraper profile provided the example for how to get started with the advanced product search, a.k.a. the speaker finder. The standard search has been extended to show results in different categories. there is some use of Soma's word limiter for the news teaser text, and for making meta descriptions out of body fields, from this topic: http://processwire.com/talk/topic/3429-how-to-set-text-linecharacter-limits-in-templates/ the design is built on twitter bootstrap framework Fredi proved to be totally essential for the client, in being able to rapidly edit things without having to find things in the admin. This site is going to replace an existing site on a different domain (ohmspeakers.com). At some point we weren't sure if/how we would be able to handle the shopping cart element, and then found foxycart, which proved to be the best choice, very flexible, and easy to implement for this type of site. FC is hands down the simplest and easiest way (imho) we could achieve things like the legacy product pages, where there are various parts and upgrades displayed on 1 page. this version is sort of a "v1", and will be expanded/improved a lot for a v2, which would happen in about 4 months.. BTW - these speakers are really good; i now own 3 pairs ... they look great and do sound totally amazing...! -marc1 point
-
1 point
-
1 point
-
feel free to share/use it. created with free picture of http://pixabay.com/en/ and (partly) free editor https://www.canva.com/1 point
-
1 point
-
I'll look into it. Some very early version of Fredi supported it, so shouldn't be that hard.1 point
-
Hi Antti, awesome improvements with the last updates!!! Easiest frontend edit solution with all features and a styled form (admin style). Any plans to add a create new page feature to Fredi?1 point
-
1 point
-
you can also use the 1-step adding of pages if all of the children have the same template: https://processwire.com/blog/posts/processwire-2.5-changelog/#adding-pages then you can set the title-field to hidden on the template-settings. or am i misunderstanding you?1 point
-
That's one way, but you will be changing all the concept of the website only because of this problem. My suggestion is that you tell the editors to write outside of PW and send their texts to someone that is responsible for pasting them in place. This is a good practice anyway and will prevent other problems as: different formatting, loosing all the work because of a page refresh or browser crashing, etc.1 point
-
1 point
-
Evan, I think your solution is a good one, but it definitely leaves the question of why it's necessary on these particular installations. It's like the database changes got previously applied, but the schemaVersion stored with the $field didn't. I will add your changes, but also think it's hiding another issue that I'd like to find a way to reproduce so can determine the source of it. If anyone is able to reproduce on a fresh install, please let me know.1 point
-
While I was it, I decided to tackle the PageTable problem also. So now the version 1.1.1 works with PageTables also (it's modal inside modal, so not exactly the dream come true, but it works if you need it).1 point
-
Just pushed version 1.1.0 to github. It adds options to hide tabs, but also new nice feature where edit area and links are shown on when hovering (fallback to normal links when using touch enabled device).1 point
-
Have 2 PW installs on the same machine, only different domains/folders One I upgraded from 2.5.29 (or so) so from dev to 2.6 shortly after it was launched Everything worked great, ah this one I updated using SystemUpdate module The second one I just updated from 2.4.0 to 2.6 and got the T_PAAMAYIM_NEKUDOTAYIM error (front- & backend) cleared everything, only switching PHP from 5.2 to 5.3 did it The first one runs perfectly fine on PHP 5.2 Just wanted to share this experience One question, is there any downside having PHP 5.3 but as cgi instead of 5.2 as apache module? Saludos1 point
-
I was just reading this post on how to make breadcrumbs in ExpressionEngine (http://bit.ly/hello_crumbly) and how you basically have to resort to a plugin to do it for you. It reminded me of some of the problems I had with EE when I was trying to use it and develop in it awhile back. One being that URLs aren't a primary/unique key to a page, natively in the system. Imagine ProcessWire with only it's root level pages and url segments, and that gives you an approximation of what you have to deal with in EE. I'm not saying it's wrong, but it's a different approach, and one that I found frustrating to work with. The post also made me realize I didn't have anything on the site demonstrating how you might make a breadcrumb trail (other than in the default site profile). It's really a simple thing (at least, relative to EE), so figured I'd post here. : <?php foreach($page->parents() as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } You may want to output those as list items or add some >> signs between items, but as far as code goes, the above is all there is to it. What it's doing is just cycling through the current page's parents till it reaches the homepage. Lets say that you also wanted to include the current page in your breadcrumb trail (which is probably redundant, but some sites do it). What you'd do is just append it to the list of parents that gets cycled through: <?php foreach($page->parents()->append($page) as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } The reason this is so simple is because every page is anchored to a specific URL and those URLs are representative of the site's actual structure. Pages in PW are actually uniform resource locators (URLs) whether on the front end or the back end. Because of that, there's no guesswork or interpretation to be done. In EE and Drupal (as examples) that data does not natively live at a specific URL. Instead that data is off in a separate container and the ultimate URL (or URLs plural) where it lives–and will be presented by default–are not as cut and dry. Yes, you can install plugins or go through strange taxonomic/channelistic/cryptic trials to approximate the behavior in other systems. And yes you can use url segments and pull/render any other pages you want in ProcessWire according to your own needs. But I'm talking about the fundamental and core system differences. This difference goes far beyond simplicity of generating breadcrumbs–it is a factor that translates to simplicity throughout the API.1 point
-
UPDATE: Fortunately, I have traced the problem. (I recalled having a similar problem on MODx a few years back) ALL of the pages which I created on local XAMPP install and migrated to the live site would throw a 403 Forbidden on save as well as pages which had content that matched the ModSecurity filters/ rules on the server. It does not like the brackets <> I guess. The pages I created on the live site had fields which were to have HTML code but were left empty, hence no error was thrown and the page was saved gracefully. Error log below: [sat Jan 17 13:13:33 2015] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(< ?(?:script|about|applet|activex|chrome).*(?:script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|" ?> ?<|" ?[a-z]+ ?<.*>|> ?"? ?(>|<)|< ?/?i?frame|\\%env)" ... [uri "/xxxx/page/edit/"] I have a few text fields which are supposed to accept HTML code and output it as is but my host does not like it being saved to the database un-escaped. This issue has been traced and is fixed for now by revisiting the template files PHP code and outputting the data some other way OR manually editing ALL offending entries in the database.....hmph BTW, my host uses HSPHERE/PARALLELS and hides its Apache version1 point
-
Pierre-Luc: on the product catalog side: everything you have in your PW arsenal, will be in your PadLoper shop also. So multi-language. image galleries etc.. all that kind of things will be done how you like to do them with ProcessWire. So multi-language products are definitely easy thing. Your idea about multilang emails is interesting - and I have it already covered. I actually don't store any templates in text files (I dislike any templates in text areas). What I have setup is very simple (but may I say clever!) thing. All the default templates are stored in /site/modules/PadLoper/templates/*.*. Those are normal PW template files. so you have all the template variables and multilang stuff available there. But I don't want anyone to edit those files directly, so you can add same templates into /site/templates/padloper/*.* and PadLoper will use those instead. So let's say we have email-order-confirmation.php template file. It's by default multilang ready, but if you want to customize it further, you simple copy the file into /site/templates/padloper/email-order-confirmation.php and edit it to your needs. And remember, you have all the template variables available, like $pages, $modules, $config etc.. Many of the templates also get $order variable, which has the current order and all it's information (customer, products, prices, taxes etc). If you want to use these templates in your own code, it's also simple: $t = $modules->get("PadRender")->getPadTemplate("email-order-confirmation.php"); $t->set("order", $order); // This template file requires $order variable echo $t->render(); That make's it sure that you always get the customized version, if you have one, and the default one for those that don't have. And then of course I have shortcuts for the most common templates, renderCart() etc - but customizing their markup is as simple as others (just creating copy of the file into site/templates/padloper/ folder.1 point
-
Looking forward to try it too. Will this support Language* fields? I am currently using Shopify (which we dislike) on the website of a non-profit I manage, and this would be amazing to have. We have roughly 50% French and 50% English people and there's no way to make this happen. One nice thing would be to be able to match output of emails for receipts to the user language (I suppose you store templates for those in text fields?).1 point
-
I think your PHP version is not sufficient enough. It need to be > 5.3.8.1 point
-
Going back to the original post, I think there was some confusion in the posts that followed as to what the problem actually was. My understanding was that the images had uploaded fine, but it was when displaying the actual gallery page that the timeout occurred. This is because the first time an image is displayed on a page at a new size specified by the template file it creates that size image and saves to disk. The penalty is that the first person viewing the page gets the slow loading time whilst all the images are resized on the fly, but in this case it sounds like a lot of images were in the gallery and it caused the timeout as it tried to create the new image simultaneously. The obvious benefit is that the system only creates these newly resized images as required, and once they're created once that's it - they don't need to be created again unless someone decides to change the size again in the template. Also, it's most likely - as in this case - that the first person to view a page and see the slow loading time is the person who just created the page and uploaded the images, so it's not going to be something that other visitors would generally encounter. It does sound like a bit of a bottleneck though with large numbers of images in a gallery, but one solution is to set the image field's maximum dimensions (think that was suggested above) so that as images are uploaded to the server they are resized if they're over certain dimensions. For most stuff on the web I set this to 1600x1200. Sure, less tech-savvy users will still try to upload photos from cameras etc where the resolution is something like 5000x2600 and endure slow uploads, but these will then be resized immediately by the max dimensions of the field itself and it should hopefully help that first page load where it has to create whatever image size is set in the template itself. I'm wondering if a solution to the original problem might be for the upload routine to scan the template for any $image->size(x,y) calls and resize them as they upload? Since each upload using the AJAX uploader is a separate request to the server it shouldn't technically timeout then.1 point
-
Hi 3fingers, Here is the code that processes the form: https://gist.github.com/outflux3/5690429 here is the form itself: https://gist.github.com/outflux3/5690423 i didn't post the form results, but that's just a table that shows the results; hopefully the processor and form code will help! -marc1 point
-
This is the only way I know to create different sizes when uploading images: <?php class ImageCreateThumbs extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'ImageCreateThumbs', 'version' => 100, 'summary' => '', 'href' => '', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHookAfter('InputfieldFile::fileAdded', $this, 'sizeImage'); } public function sizeImage($event) { $inputfield = $event->object; if($inputfield->name != 'images') return; // we assume images field $image = $event->argumentsByName("pagefile"); $image->size(120,120); $image->size(1000,0); } } https://gist.github.com/5685631 What I don't know is if it really makes a difference (I guess), and if using drag and drop ajax upload and old school upload would process image one by one. My suggestion is to also upload image already in 1000x* pixels because if they upload 3000+ px images it will just takes a lot longer.1 point