-
Posts
4,054 -
Joined
-
Last visited
-
Days Won
67
Everything posted by Pete
-
Done: http://processwire.com/talk/topic/4763-js-updates-in-new-admin-templates-october-2013/ I think I got the lingo correct, but I've never been very good with using the correct terminology, so if there's something silly in there or something that could be explained better then @ryan please edit that post.
-
If you are having trouble with a module you've created or are using which is no longer functioning with the new admin themes, this is due to some changes in the admin page markup in the new admin templates. The class .ui-widget-content is no longer used in the new themes aside from specific modules such as FormBuilder, and some modules used it as a point of reference in jQuery selector statements which will no longer work. The fix, which maintains backwards compatibility with old themes, is to change the module's .js file to replace this: .ui-widget-content with this: .ui-widget-content, .InputfieldContent Please use this topic to post any other fixes or modules that you encounter issues with relating to JavaScript whilst using the new admin templates.
- 1 reply
-
- 4
-
-
Good point ryan - I'd already forgotten about old themes I've updated the examples in this topic to match yours. I certainly wouldn't remove jQuery UI and switch to something else though - I think there are potential issues with some modules maybe using parts of it so that would cause more headaches in my view (though I admit I can't think of any off the top of my head). I think as long as we're using jQuery (forever, right? ) then it makes sense to stick with jQuery UI unless something massively improved suddenly appears. You're always going to have something that "just works" (aside from any occasional bugs ) if it's by the same people who write the jQuery codebase anyway.
-
@Soma - I posted the fix to most/all JS issues in modules a few pages back: http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=45667 Just change all instances of this: .ui-widget-content to this: .ui-widget-content, .InputfieldContent and you're working again Just tested locally and this fixes it nicely. I know it's a bit of a pain, but surely less superfluous classes in the admin theme is better? Certainly the ui-widget ones used to be there because of jQuery UI and the Inputfield ones are there because of ProcessWire, so theoretically will never be removed and are more reliable to use in jQuery selectors. What might be nice is if we could somehow automatically scan all the modules in the modules directory where they have JS looking for .ui-widget... and then we will know which ones need attention and could maybe notify the authors?
-
Bit late to the party, but there is actually some merit to keeping different colours as separate products anyway. It's a tricky call on some websites, but if you keep them separated by colour, the customer can see all colours when browsing a product category, otherwise there is actually a chance they will see a blue t-shirt for example and not click through because they wanted a red one, even though it is an option if only they had clicked through. Of course if you're selling hundreds of products with many variations this could become messy, but it also allows you to do things like sort by colour easily and have a search list of all red shirts for example with pictures in a list or grid. The problem with variations where you get a bit more complicated with a size and a colour is that you ideally want to be able to manage them easily (and the list can get long!) but also be able to easily turn certain colours and sizes off (it happens occasionally that there might not be an XXL manufactured in green but there is in every other colour). This sort of thing usually results in a reasonably complex variation grid that I couldn't begin to think how to best code, but I know that as an occasional end user it is actually easier on my brain to separate out by colour rather than manage a large list of different combinations of variations. Just my thoughts
-
Like this: http://processwire.com/videos/page-fieldtype/ EDIT: But now I'm re-reading it that doesn't sound like what you want at all...
-
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.
-
Lots of images to resize -> timeout in frontend...
Pete replied to titanium's topic in General Support
What I meant was people seemed to be trying to fix a front-end issue with a back-end solution that wouldn't solve it with the original poster's code Didn't mean your reply, rather earlier ones. -
Well I wouldn't agree that that's what most people want (are you always adding pages in the same section one after another? Probably not in most scenarios, probably on news sites though). That said I like the idea of the module where it is useful. There is another helpful module as well called something like page save actions that allows you to add another page after saving rather than even going back to the page list
-
Hi Mark and welcome to ProcessWire! Firstly, if you're referring to the features that start at about 1 minute into this video then I'm afraid not, not yet at least. It is on the roadmap for Winter 2013/2014 but ryan would have to weigh in on this topic as I'm not sure what his thoughts are on the subject - I know it has come up a few times on the forums though which is why it's on the roadmap. After watching that video and having worked with workflows once before, that is an excellent implementation of what can be a complex feature. I can see how it could also be used in ProcessWire on any field you could add to a template (not necessarily how to code it though ) and even with workflows spanning multiple templates or just specific templates with lots of fields and different approvals required. It might be nice, though not sure how useful this would be, to have multi-step workflows where an editor can see the fields they need to see and at the next stage the approver sees some other fields that we don't want to concern the editor with but which need filling out before a page goes public. This was a requirement of a CMS used in government that I had to get to grips with a decade ago, certainly, so it's something I know that larger organisations potentially require. In the meantime if you let us know the workflow steps you would like to implement it might be possible to do something simpler with a module, depending on the complexity of your requirements. Quite often, explaining what you are trying to achieve will result in some code appearing in these forums I guess another good question whilst we're on this subject is: does the workflow system in Concrete5 Enterprise do everything you need it to do or is there anything you would change? I'm guessing you've either tried it out or watched the video I linked to so it would be interesting to get more feedback from people who've used workflows to see if that particular implementation looks like a good direction to go in.
-
Lots of images to resize -> timeout in frontend...
Pete replied to titanium's topic in General Support
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. -
I'm with you on this one Adam. There are a few things that I think fall under "config" that are difficult to achieve without a module and some server-side SASS compiler (hence that PHP one I linked to several pages ago). In my mind, and I appreciate there is some work involved, the admin theme would ship with a special module for configuring Toggling of page titles in admin Font size (I'm with ryan on preferring the smaller font actually ) Basic colour selector for people that don't want to compile SASS Could even then have a selection of admin fonts Those features in a special config module would be killer if they could be saved per admin user as you're also helping to adhere to disability standards with font sizes, colours and font faces which is another bonus, whilst letting people work in an editor they feel comfortable with (anyone else set up their own colour/font scheme in their favourite text editor? I know quite a lot do!). I'm not saying any of that is remotely easy - it would require some thought certainly - but I can see how it would be done and how such a simple addition (from an interface perspective ) would make for a totally killer admin. And again I unfortunately have no time or I'd build the module already
-
Pretty sure it only accepts .jpg, .gif and .png - what file type did you try?
-
Returning articles with the same article, date, category, and tags
Pete replied to BeardedCanadian's topic in Getting Started
Hi there The search API is the API. It's all the same thing, so only one thing to learn. URL Segments are just a way of passing some additional things to the page so you can fine tune what you're displaying. If you had a page called "Articles" with a template "articles-home", what you might do is turn on URL segments and then do something like this, where urlSegment1 is what thing you want to filter by in terms of a and urlSegment2 is what you're matching against <?php if ($input->urlSegment1 == "author") { // Assumes there is a specific field in your article template called "author" and you would match by their name from a URL like www.yoursite.com/articles/author/ted-danson/ $articles = $pages->find("template=article, author.name=$input->urlSegment2"); // As you can see we matched urlSegment1 against the fictitious URL above and the above $articles variable will hold all the IDs for articles by the matched author, urlSegment2 /articles/ is a real page, /author/ is urlSegment1 and /ted-danson/ is urlSegment2 } elseif ($input->urlSegment1 == "category") { // Now imagine our URL is www.yoursite.com/articles/category/autobiographies $articles = $pages->find("template=article, category.name=$input->urlSegment2"); } elseif ($urlSegment1) { // If someone is still passing an URL segment and it's not one we recognise and have dealt with above, it would be best to throw an error. People could be typing in all sorts of rubbish otherwise like www.yoursite.com/articles/bunnies/ninja/ throw new Wire404Exception(); } else { // So in this very last one we've not got any URL segments at all, so we probably just want to list the last ten articles with no search parameters applied $articles = $pages->find("template=article, sort=-created"); // This lists all articles in reverse date order // You can also add ", limit=10" stragith after the word "created" in the selector above, or any of the ones above to just return a certain number of results and then look into pagination elsewhere on the site and forums to implement that rather than display potentially thousands of results on a page } // And now you have your $articles you can do something like this (I've assumed you've added a field to the article template called "date": foreach ($articles as $article) { echo "<h2>$article->title</h2> <p>Written: $article->date</p> <p>$article->summary;</p> <p><a href='$article->url'>Read More</a></p>"; } Now the only reason I could see for you matching articles on a specific date was if you were maybe reading articles on a busy site and at the end of a specific article you wanted to see a list of other articles on that date. Even so I can't think why you might want to do that, but here's some code that might help - remember you've now just read an article and at the bottom of the page we want to list other articles on that date: <?php // We're getting articles on the same DAY (the exact time as the current article would be a little pointless as you're down to matching the second in that case) // We'll assume that the date the article is saved in ProcessWire is the date you want to use to find other articles posted on the same day, however it could easily be your own date field - for the purpose of the example below this just means I'm matching against the "created" field in the database $startOfDay = date('j F Y', $page->created); // Since this will be a horrible timestamp to the SECOND that the article was published, we're turning it into something that reads like this: "12 September 2012" $startOfDay = strtotime($startOfDay); // Then we're turning that from a human readable string back to a timestamp, except now it is 0:00am on that day - the start of the day! $endOfDay = date('j F Y', $page->created) . " +1 day"; // Now we're doing the same again, but you can tag " +1 day" on the end of the string... $endOfDay = strtotime($endOfDay); ... and strtotime() is clever enough to add a full day onto the date $articles = $pages->find("template=article, created>$startOfDay, created<$endOfDay"); // Easy huh? Not if you don't know some of the above date functions obviously, but it's well worth looking on PHP.net as everything before the line directly above involves just some pure PHP to manipulate the date and is well worth spending a little time learning. Let us know if you need any more examples. The search functionality just uses the same functionality above from what I remember except it sends the search query to a specific search page and then matches the string the person entered against various fields like "body" and "summary". It's all the same sort of code behind the scenes. This is also the reason you won't see a generic example - they just don't make sense as everything uses selectors to find results (plus real-world examples are easier to understand for the most part): http://processwire.com/api/selectors/ -
I'm also interested as there is one scenario for an intranet that I've got in my head where it wouldn't be a bad idea to have the whole thing as Process modules in the backend and simply not have a frontend. The only problem there is that you still have to have the root page I guess, but it would be good to make something like /login/ the default page in this scenario and run the admin from just the root instead of /processwire/
-
Love it I was naughty and searched for cottages available in the past and it still returns results, but not sure if availability is linked in yet?
-
Top graph is posts made per month, bottom is cumulative over the same time period. Nice! It's not gone vertical on the cumulative posts, but that's fine as I'm still many pages of unread posts behind where I'd like to be
-
Over 45,000 posts now too folks
-
Just looked at the video for Scout App - works well for Windows or Mac and the video shows it as simple to use for those of us who don't see why we should be doing any command line stuff and installing Ruby when there's a simpler (lazier) solution Though I also like the look of the others - Codekit is especially interesting for its other features at a low price tag!
-
One thing to note with the new theme is that in one module I'm working on that uses jQuery to watch certain elements for changes it no longer works because I assume some of the elements' parent containers have changed. Not difficult to fix, but might break a few modules is all I'm thinking. EDIT: To fix mine all I had to do was change references for .ui-widget-content to .ui-widget-content, .InputfieldContent
-
Yep, basically what Martijn said. Go to Setup -> Fields -> Add New Field Add a name and label for your field and change the Type dropdown to File Under the Details tab you will see allowed filetypes and PDF is in the list - alter the list to suit you Change Maximum Files Allowed to however many you want - perhaps 1 in this case? Save your changes Add to your template That's it really.
-
Sounds like it could be useful for centrally storing images on a different server for multiple sites, but I have no idea what scenario that would be used in.
-
Wonder if this is of use for less tech savvy users: http://leafo.net/scssphp/ Theoretically something that could be bundled into a module
-
I meant to say "when time permits" and not sound like I think you actually have any spare time
-
Like it - nice additions One thing I was thinking about a while back was being able to maybe use a colorpicker to select 3-4 primary colours and have a module save those to a CSS file so the admin colours could be changed easily. Might be something worth considering time-permitting? Obviously you can end up with some pretty garish colour schemes that way so would be one for superusers to control I think.