Leaderboard
Popular Content
Showing content with the highest reputation on 01/09/2013 in all areas
-
AdminSaveActions (Was: After Save Actions - guess why the rename?) Admin Save Actions adds the possibility to choose where the browser gets redirected after saving a page, template or field. Admin save actions are displayed just before the save button in a collapsed container. Chosen action can be saved in a cookie for current user by checking "Remember this setting". By leaving this option unchecked upon save, the chosen action will not become the default. Why? Some of you wanted something like this to exists in ProcessWire - and so did I. I've read discussions here, here, here and here carefully trying to cover at least most of the options discussed. I know this implementation wont satisfy all the needs, but I'm looking into adding some things afterwards to cover even more of them. I called the first version of this module PageEditRedirects but decided to to change the name in to a more descriptive one. So that module got deprecated as of now (and does not exists at GitHub anymore). This new version also does not require PW 2.3 but works just fine on PW 2.2 as well. Special thanks A module by Adam Kiss (ListAfterSave) implemented some of these actions a long time ago. Thanks to Adam for letting me use the ideas introduced by his module. There are actually some things there my module isn't going to cover even in future versions. Links AdminSaveActions can be found from the modules section. AdminSaveAction is downloadable from GitHub. (Edit: added link to the modules section. Edit 2: Implemented config option + version bump. Edit 3: Removed feature list - see GitHub.)9 points
-
We have many users that have come over from EE, just like we have many users that have come over from WordPress, Drupal, MODx and Joomla, among other platforms. These users are enthusiastic about ProcessWire and like to share their enthusiasm with friends. Please don't confuse the title of this thread as being something the project is trying to pursue, because it's not. I'm assuming the OP is a current/former EE user that is enthusiastic about PW and wants to share that. We are not actively trying to benefit from changes at EllisLab or trying to pursue EE users. If I were an EE user, I would want what's best for the company behind it and would stick with it. When those changes were announced, I went to the #eecms hashtag to see what all the fuss was about. There were other projects being opportunistic about it (the Perch one was actually kind of cute). We were silent on it. Just because there were current/former EE users talking about ProcessWire does not mean that ProcessWire is trying to pursue EE. EE has nothing to do with any "cause" here. I changed the theme shown on the homepage because users here thought it would be better if it showed exactly what you see when you install, until we get the rotation up. We have several sets that are going to go in there (rotating) and the one that was there previously is one of them. Now that the default admin theme is in there, there have still been folks that say "that looks like EE". I designed that admin theme and can say for certain it takes no inspiration from EE. I really don't know if the other admin theme that was in there takes inspiration from EE or not. But looking through screenshots, it seems like there are similarities and differences. I'm not convinced anyone was trying to copy the look of EE. Design trends and interfaces for similar tasks are bound to bear some resemblances to each other. People need to step out their front door. There is one thing I can be certain of though, and that's that I'm glad people might say "that looks like EE" and not "that looks like Joomla". I was glad to see this. It came along at the right time. If I was an EE user, this would make me a lot less concerned about the changes in support plans. Glad to hear PW and others are being looked at. We are thrilled to welcome any EE users. Still, if folks are happy with everything about EE from the software side (even if a little angry about EllisLab changes in the short term), they shouldn't abandon it. CMSs aren't religions, and it's okay to use more than one. It is curious to me that Blocks gets mentioned despite not even being out. Blocks appears to be built as a platform specifically targeted towards EE users, and that's probably why. The model behind that one is ultimately a paid model. EE itself is inexpensive in the grand scheme of things. Blocks apparently takes that further by just making the core free instead (a little bit of a trap). But the end result is the same: you'll be spending significant amounts of money on either, because both are built around a paid model. They are there for the money. And that's perfectly fine so long as the user understands that. But with EE, at least you are getting an experienced platform, history and track record. My opinion is that EE users looking for a change should look outward (beyond the money model) not inward. One you have your "a ha" moment with ProcessWire, you'd lose all interest in EE or anything like it. But EE users have to be willing to let go of learned complexity, baggage and preconceptions about CMSs in their mind. And not everyone is ready for that. If an EE user either isn't ready or doesn't find what they are looking for by looking outward, then they should instead look beyond the short term angry EE chatter. EllisLab is making long term decisions for the benefit of the company and the software, and it's actually a good reason for those folks that really like it, to stick with it. Individual developers are not going to be the ones paying these $20k yearly support fees, so it shouldn't be an issue. It's the big enterprise clients that will pay those fees, and they'll think it's a great deal relative to their old CMS monsters. What's good for EllisLab will ultimately be good for the people that want to implement and use their software. This is confusing quantity with quality. If quantity is the measurement, then EE isn't there yet either. If it was, I don't think EllisLab would be changing their business model. For better or worse, the EE ecosystem is also built around a money model. That ecosystem rises and falls with a business rather than the product. PW has always been about quality and has never been about quantity. I started this project as the only user for many years. When I put it out there, I intended to keep it going for the long term regardless of how many users we had. We don't get paid here. We do the work because we love it. They may be huge now, but Drupal and Joomla will really have to fight hard to be relevant in the future. They carry a lot of legacy ideas and methodology, and they kind of have to. They can only lose market share from here, so it seems like they are pursuing defensive growth strategies. When a Drupal, Joomla or WordPress developer gets a taste of ProcessWire--and really gets it--they are changed. I think that ProcessWire and systems like it will make it difficult for the likes of Drupal and Joomla to stay relevant in the long term. I'm sure EllisLab sees this too. But EE users should at least feel good that EllisLab is pursuing a growth strategy that seems geared towards growth rather than maintenance. WordPress is not great software either, but we can all learn something from the way they've grown and likely will continue to. I wouldn't trade our ecosystem or software with any of theirs. And for those that measure by quantity, we'll get there too, but we won't be counting. People from EE are totally welcome here. I'm glad you've joined the discussion. But want to be clear we are not hoping to achieve anything in that regard. If our strategy were to pursue users from other CMSs, we wouldn't be pursuing EE -- it only represents a tiny sliver of the CMS pie. We only want to gain users based purely on the quality of our software and community, and the good reputation that accompanies it. This is an open community and we don't control what gets posted. The only reason you see EE mentioned here is because of EE users that are now using ProcessWire. I appreciate their enthusiasm. While I have positive feelings for EllisLab and EE, it is not on the radar here as having anything to do with our project, goals or strategy.5 points
-
5 points
-
We're planning to have JSON export/import for fields. Templates are a little different in that they have a file on the disk too. But we can still make the data structures templates portable in the same way as fields.4 points
-
Greetings Everyone, I sensed a buzzing in my ears... Oh, hello Joss! Quick bit of relevant history: Joss and I have tag-teamed on numerous, lengthy discussions on core CMS issues, stretching back into some obscure Joomla technical groups where he and I voiced loudly the need for that CMS to adopt better custom-field options, as well as other issues. Those were heated discussions, zeroing in on gaps in Joomla's central functioning. But even in those inherently critical discussions, Joss and I both stayed positive and constructive and tried to do our part to move Joomla forward to improve. In those discussions (which I could dig up for anyone who is interested) I often made comparisons between Joomla and other systems as a way of exemplifying what I thought Joomla could become -- again trying to do so in a constructive way. Joss and I remained a virtual tag-team throughout those discussions, online and offline. Which brings us back to the current discussion... I spent a good portion of 2011, and most of 2012, on a quest to test several CMSs and make an honest assessment of them. By the end of 2012, I had deeply tested the following systems: ProcessWire PyroCMS ModX ExpressionEngine Joomla Drupal Concrete5 It's pretty clear which system I have chosen! But that's not the point. The point is, I gave all these systems an unbiased try, and I learned a lot by looking at them honestly. (With Joomla, I did more than "try," as it was my core system for about four years.) Some of these systems have such large gaps in their capabilities I could not continue using then for the kind of sites I want to develop. But others on this list have strong benefits. Still, in the end, the flexibility and complete openness of ProcessWire's API made it a winner across the board for me. The systems that come closest in my mind to ProcessWire's capabilities are EE, ModX, and PyroCMS. Again, each of those systems has its benefits that ProcessWire could learn from (perhaps we could get into specifics in another discussion). But again and again ProcessWire proved itself to be a more natural and flexible system. We should acknowledge that there is a development philosophy behind each system that appeals to certain kinds of users. For example, users who do not want to look at code, and users who want templates that lay out specifically what goes where in their sites, will be happier with systems like Joomla or Drupal. If someone is just counting the number of available extensions, ProcessWire can't compete with Joomla or Drupal (which have tens of thousands). I don't think the raw number of extensions is meaningful at all, but that is also for another discussion. To many users, there is comfort in high numbers. For people who want a fairly open system, with control of their URLs, but which still make some templating assumptions, Concrete5 and PyroCMS are good. When you get into "completely open" systems you can seriously compare EE, ModX, and ProcessWire, at which point there are more refined choices like the use of tags, how files are handled, the speed of the interface, and more. The specific comparisons go on and on... I much prefer positive discussions. That does not mean we cannot be critical. It's more a comment on the goals of a discussion. It's depressing when all you have achieved is a slamming of something (or someone) else. It's much more exciting if in the end you improve your system (or yourself) by taking an honest look around you. Also, to be blunt, it is smarter to be constructive. Of course, it's also more work: it's just so easy to slam someone or something, especially in a forum where you know everyone already agrees with you! The fact is, EE, PyroCMS, ModX (and other systems) were built by very capable and creative people. We should strive to learn whatever we can from their strengths and weaknesses, while simultaneously stating clearly where ProcessWire does something better. In these forums, we are always communicating to at least two vast audiences: 1. People already dedicated to ProcessWire 2. People testing the waters or shopping around For both audiences, we are better off being positive and constructive. Although there is lots of anger and criticism on public forums, I believe that most people are attracted to a positive environment. For audience #1, we are better off pinpointing where ProcessWire can improve (while being constructive). For audience #2, it is important to point out where ProcessWire is better than other systems (while being constructive). Bottom line: I have found that ProcessWire is better across the board in significant ways. There is definite value to pointing out where ProcessWire is better. We just need to do so while being aware of the intelligence of other systems. Thanks, Matthew3 points
-
I think it is always difficult, but quite natural to talk about the competition. However, the nature of the internet makes it rather more complicated than before. In the "old world" (which I find I miss more and more) this conversation would have taken place down the pub (that is a "bar" to you foreigners!), would have been full of idle speculation and pure BS and that is where it would have stayed. Now, of course, not only is the conversation "published" but is also searchable - and therefore it is good that this conversation is congenial. I have never used EE, and since my main income is not from web design it is unlikely that I will ever do so. I have seen screen shots of the admin and it looks exactly like the one I had on my own-designed Dreamweaver based CMS back in 2001 (A web oddity). However, since that was only ever used by 20 financial journalists I can more or less guarantee that none of the EE people ever saw it, so it is coincidence, nothing more. At the end of the day, you should never design a UI to be "different" you should design it to be workable, and by that criteria, in the end everyone's UI is going to be pretty similar, I suspect. There are four things that make a good application: Strong, under-the-hood design Easy to use and logical interface (so, probably not designed by a coder! ) Versatility to allow the client to achieve what they require and to get their true money's worth. A good design team that works to produce a strong, competitive product rather than achieve some sort of philosophical goal (even if the product is ultimately free) But there is one other aspect that sometimes gets overlooked - the application must have a clearly defined market. Being all things to all people can seem very glamorous and noble when chatting round the water cooler, but if that becomes the driving force behind the product, the result can be confused, messy and fragmented. I think ProcessWire has a clear goal, that is what makes it attractive to me, and I think it is why (with a bit of a push) it can have mass market appeal. That goal: Create a website. Because for 99% of the time, that is exactly what people will want to do with it - create a website with 'n' number of pages, all pretty similar with some bits of dancing and fun attached. Not wonderfully headline making, but the practical day to day job of business website design. ProcessWire does have the ability to address far more complex needs too, of course, and the fact that it can be hooked into other systems (or they be hooked into it, perhaps) means that it is wonderfully extendible for the knowledgeable designer. But that does not distract from the basic fact that it is a great way to produce a solid, secure, well balanced website and I think as long as that is kept front and centre, it will do well. As for the competition? Well, as I said at the beginning, it is natural to talk about them, and it is wise if one sees the competition getting something wrong to learn from that - there is nothing more idiotic than repeating someone else's mistakes - but in the end, the real focus has to be in getting one's own project right, whatever the competition are up to. As Matthew Scheneker knows, I like to be optimistic about the future of a project and get very grumpy when my optimism is undermined by idiotic, egotistical, idealogical battles that have nothing to do with good business or good R&D. And strangely, that is what I have been enjoying most over the last couple of months - a developer and a supportive community that has a healthy and realistic "can-do" approach that is of real benefit to the users. On that basis, the fact that ProcessWire is also a very good and solid tool is a very sweet bonus! Joss (PS: Years ago I had a very interesting bit of advice from Victor Kiam who was a client. He said that when a project is your baby, then keep it as your baby, keep control and don't share it. Once it gets to a size where you have to share it or you are getting a little weary of it, sell it completely and go and find a new baby. )3 points
-
I see your points and fully agree. At first i wanted to start this topic in the modules section but realized there were mostly "look at my finished modules" topics, so i decided to post it as a general wish. Could somebody please move this thread to the "modules" section? //edit: I apologize i forgot to also thank all contributors in my first posting and would like to do so now2 points
-
2 points
-
Is this code block really editable without breaking indendation: <?php echo "testing testing"; if($thisWorks) { echo "Antti is smiling"; } else { echo "Antti is crying"; }; It works!!!2 points
-
My biggest fail was I created a new universe and after seven day of hard work I was about to finish but unforunately I couldnt save it because it was too darn big it just disappeared in a big black hole...2 points
-
I did something similar in 2011. The good thing was it was a personal project, the bad thing was it was a few months' worth of evenings that I'd lost Some evenings were more productive than others of course so I probably only lost 2 weeks of work in real terms, but it still hurts. The end result was that, since it was a ProcessWire site, I came back to it a bit later on to re-do the bits I'd lost and not only was I quicker at it the second time around I actually did a better job of it too in about 3 weeks worth of evenings. So yes, I try to backup often nowadays2 points
-
It's really easy to do the path stuff - you can split out that information by running a PHP explode() function on the path name and then picking out the year, month and day and then have whatever structure you like in PW. The main thing I keep asking though is more important and harder work - do you have an example of one of the articles so I can see the contents and suggest how you would parse all that? Basically if I could see that, I can pretty much give you the code to do it as I've got a converter script on my PC here Another question I asked earlier was how images are stored for each article (when they have images)? Are images just in the folder with the file that contains the text? The paths can stay the same as the text versions if you like - /issues/2013/Jan/08/ for example, but then have a more meaningful title on the end, like "news-story-title" if you like. You could also do away with the date in the path altogether and just have /issues/news-story-title and people can use an archive page to go through the days/months/years. But I'll rewind a bit as the harder part will be importing the articles. Iterating through your current directories, assuming the path you have for the files is consistent back through the months and years is easy, but I'm itching to see the content of one of the text files to see how hard that side of things might be2 points
-
Not so much before & after PW, but just after and a couple of days later... https://plus.google.com/photos/108086096046069388419/albums/5831478825607635953/5831478828859887026?authkey=CMHO9sqY0OLVUg2 points
-
Ryan That is a good post and makes a lot of sense. When I moved over to PW a couple of months ago it was through recommendation because I was finding various platforms frustrating. It was a big jump for me since I am not a natural coder and far more of a writer and editor. Interestingly enough, I have never had any sense that this project is aimed at anyone except web developers/designers that need a tool to achieve a purpose. That could be anyone - those that have used a lot of the CMSs or those that have used none. ProcessWire would suit both camps amicably, to be honest, without needing to be highly competitive. My real job has always sat me right in the middle of the media, advertising and drama world and I thought I was used to darlings and luvvies pouting about each other. I have to admit, the amount of drama queens I have run into in the CMS world has been a bit of a shock! On that basis alone, ProcessWire has been wonderfully refreshing in its professional and non-confrontational approach. Almost controversial, I would say! Right, back to work everyone! (In my case that means finding a couple of country singers in Nashville who are up for a challenge!) Joss2 points
-
Thanks, netcarver! Sound advice and I believe you've helped me solve it. The function isn't static, no. I didn't realise that method of attaching a hook was only for static functions. I've not looked into how PW actually makes the module methods hookable but I had sort of assumed that it creates its own methods without the underscores which call the method and associated hooks. If so, I guess these are static. I have pretty rudimentary knowledge of both object orientated PHP and PW's internals though. By zero-ing on line 53 you've made me realise my error. The function was getting called but as I was calling it with the underscores it was not calling the associated hooks. I've removed the underscores and the hooks are now working. Much of the business logic you'd use to verify the payments is outside of the scope of the module as it stands, such as checking the email and postal address of the transaction against an order, or checking the orderID matches that returned by PayPal. That said, checking the transaction ID is certainly something that could be done if I expand it to keep track of all payments it receives. Any other suggestions welcome! Stephen2 points
-
Pages will definitely scale quite far. But there is certainly more overhead with a page than there is with a plain DB table. As a result, when you are talking about storing huge quantities of data, I would keep your pages to represent the visible URLs on your site. If each row of data isn't going to be related to a unique URL in your page structure, then there really isn't a technical need to store it as a page. Though if you don't need infinite scalability, you may still find using pages for that data to be more convenient. But since it sounds like you do need near-infinite scalability, going to the DB sounds like a better choice. ProcessWire Fieldtypes are designed to represent simple and complex structures in this way, while still letting you use the API admin interface to handle it all. However this does require developing your own Fieldtype and Inputfield to manage it (which actually isn't too difficult). If you don't need an interface and/or PW API access to manage it, you can also just go straight to the $db object as if ProcessWire wasn't there. But this isn't as nice or fun as having your data still be connected with ProcessWire.2 points
-
Maybe you could try createjs.org, looks very promising. PS: thanks for this great software!2 points
-
Any topic like this is bound to get negative at some point, whether it be people like me balking at the price of things or others with different dislikes. All that aside, what would we achieve from more hands on deck? Well let's see - the majority of people here help each other out. Many people contribute ny way of modules (which are simple to write compared to other systems). Others spread the word because they like the project so much. It's not a case of bums on seats - we've got a growing commmunity of active users who help each other and enrich the project going forwards. We've been lucky enough to attract a lot of talented people who used to work with other well-developed systems who now prefer ProcessWire because it genuinely saves them time and stress and makes building websites fun and quick. It's not for everyone though - you can use it to build pretty much everything you might need in a website but you might want to take a step back if you were thinking of building a specific web application or other project that requires complex relationships in the database (although some folks here are managing to build those in ProcessWire too). We're no Wordpress/Joomla rival in terms of numbers, but all I see with those platforms is clunkyness and bloat personally. Modules for both are hit and miss as most here are aware, and clients will often push one of those systems for the sole reason that they've heard of them before and trust the name. I'm glad we're not that big yet because we're at a stage where we have some quality modules and can keep an eye on them and suggest improvements to them. It's not imposed quality control, it's helping each other out. Not sure where my train of thought is rolling off to, but I think the bit about what we would achieve by people coming here from other systems is that we often then have the skills as a community to help others who come from those systems. We often see questions like "I do this in my old CMS, how would I do it in PW?" which is great as the more experience we have in the community the quicker we can help those people out. As for any perceived plagiarism with any of the admin themes (I've not used EE so don't know which theme you're referring to, hence my choice of wording), if there is an issue then please inform ryan and I'm sure he will look into it. If nobody makes a complaint then we can't take action. I hope none of that has come across as negative. I'm not the best at being impartial on forums and I'm just trying to get my own points across. EDIT: @Antti - fixed, there are a few styling issues left I think.2 points
-
Nate, thanks for the good and honest post. You mention few great points that I do agree. I wasn't too keen on the general tone of this topic and it is great to hear your thoughts. But there are few things I would like to mention: I disagree. For most of us there is a lot more and on higher level than EE or any other CMS out there - that is the reason why we use PW. I had the freedom to choose the next CMS platform for our company. I did evaluate most of the products out there (open source or not, in our projects EE license fees are next to nothing) and PW came out as clear winner (there were 0 third party modules / themes then by the way, January 2011 - PW 2.0 was just released). Now two years later I couldn't be happier - PW has been great for us. Well... I think it is natural that people want to share the good stuff they know. I think for all the people here in this topic the basic intention has been purely honest and nice: "hey, there might be EE users that aren't happy - I hope they find PW since that might solve their problem". But that kind of discussion easily goes to little attacking tone that can annoy people. About to step up our game: I think if Ryan can keep even 25% of the phase that he is developing the core and the growing flow with 3rd party developers and designers keeps up, we are doing just fine No need to try actively catch people from other products - but no need to be shy or shamed about using this great product. EDIT: Pete, alert alert - IP.board is messing my quotes!2 points
-
I get mixed feelings replying to this topic to be honest though, let's do it: The title says "...and how ProcessWire could benefit" but, nobody goes into any detail about how or why PW would benefit from having EE devs come to PW. Or for that matter why EE devs would benefit from PW minus it being free (there are other CMS that are free I might add.) Posting in the EL forums wouldn't be cool by the way. Thankfully that idea looks like it was shot down! Seems like you are having fun with the Alternative.to which, is find, whatever. Having admin themes which look like EE isn't helping your "cause" if you want to call it that. I know these are user submitted though, putting them on the homepage gives off the wrong impression especially to EE devs I've talked with. Most of which do not like "plagiarism" even if only closely resembling the EE CP. Glad you changed them out for the default ones. You guys know why you like PW though, someone who has been using another CMS everyday for the past 5 years, for example, might just see PW as noise along with all the other CMS out there. I've talked about it before though, there are plenty of people who prefer a template engine over strait PHP or PW API however much you might think the API is just as easy. Is PW like theming for Drupal or Wordpress? Not even close and I commend you on your work with the API though, like I said, it may not be everyone's cup of tea. To be honest there is currently quite a bit of CMS "research" taking place within the EE community though, I'd say most people are just testing the waters and probably a bit less now that the initial shock of the EL changes have settled down a bit. Plus, folks are getting help via the new ExpressionEngine StackExchange site so free support is better than ever and there are more options for support then ever as well. Some people have abandoned EE altogether though, that's common with any CMS or Framework when there are major changes. With that said, PW is being looked at yes though, so is PyroCMS, Statamic, Perch and very importantly Blockscms which probably is most likely to put a dent in EE if any significant dent are to be made. Others are being looked at as well (maybe even some RoR and Node stuff.) PyroCMS is moving over the Laravel 4 (away from CI) which might just propel it's future use. Hard to say. I'm sure there will be other Larvel CMS popping up (other than pongo that is.)Statamic is different in that it's a static CMS similar to say Jekyll though PHP based (and commercial I might add which believe it or not allot of people do like.) In it's current state it could definitely compete with Perch in the "Lite" CMS arena which by the way isn't so small any longer (the Lite CMS arena that is.)Perch is another one people have been looking at though, of course that's for smaller sites too. I need to give v2 a try.Now Blockscms is a whole different story altogether and is the most anticipated to compete directly with EE once it's out of private beta. I'm not going to go into all the details though, yeah, it's coming. We'll have to see what this new year brings for that. This is really a topic in itself so I won't extend this already long post out any more on that. WIth the recent changes I think allot of people might consider using some of the other options I listed especially for personal sites or smaller client sites where as in the past they would have just used EE for everything. Allot of this stuff wasn't even there two years ago so, sometimes it's all about timing. Currently there really isn't anything that is on the same level as EE especially in regards eco system. No offense but you're not there yet. You have Drupal, WP and even Joomla of course (all are "free") which have huge eco systems but, yeah, let's not talk about those any more than I hear Drupal 8 is suppose to go Symfony 2 so I'm curious to see how that turns out. Anyway, I guess I'm not quite sure what you guys are hoping to achieve by having people come over from EE especially since there isn't anything for you to gain other than more hands on deck (which I guess I understand.) Trying to reach any users via a forum post is just senseless if you ask me and you're going to have to step up your game in many areas to compete with what's coming down the pipe. I look forward to seeing the future as things unravel for PW and all those involved.2 points
-
2 points
-
2 points
-
You can't use any operator except '=' when querying path or url from the database (like when using $pages->find). This is because the path doesn't actually exist in the database, so there's nothing to perform comparisons on. It is generated at runtime based on a page combining its name with the names of its parents. It worked with '=' because we pulled a few tricks to convert a path into a big left join statement, in an attempt to match it. And this actually works very well. But it doesn't translate quite as well to other operators. I should have had the engine throw an exception when you used an operator it didn't support for that. Instead it just switched it to an '='. So I've updated it so that it now throws an exception instead. I've also added a new module to the core, called PagePaths. When you grab the latest dev branch, do a 'check for new modules' and you should see it. Once you install that, it goes and sets up a table with all the page paths and a means of querying them. This enables you to use any operator when querying path or url, including all the partial text matching ones like %=, *=, ~=, ^=, $=. As a side effect, this module also brings potential performance improvements to other queries, as it eliminates the need for the left join trick I mentioned above. (Though in my initial tests, it doesn't seem to be a measurable improvement). I will probably have this module installed by default for new installations of 2.3. But won't have it auto-install to existing installations. That's because it has to generate an index of all pages in your site--a potentially resource consuming process. For instance, Antti's 100k page site probably won't work with this, as it's no small task to go and build an index for 100k pages after the fact. But if you aren't running a massive site already, this module is one you probably want on most sites, so I went ahead and included it in the core.2 points
-
It shouldn't be too difficult to come up with a script to import the text in the flat files to pw pages.2 points
-
Hi Ryan, first - as this is my first post - let me say i just started using processwire and already fell in love with it. You're doing a great job! There already are several threads about replacing the current wyswig editor (TinyMCE) with [insert $editor here]. I did a forum search and wondered why no one mentioned implementing in-page editing like most "big cms" (drupal 8, typo3 neos, symfony cmf...) currently are. In my opinion this is an absolut killer feature from a clients/authors point of view. As create.js is just an editing API people could also start using whatever editor they like (currently availabe editors are: hallo.js, aloha, ckeditor, redactor). If you never read about create.js you should visit http://createjs.org/ and have a look at the demos as well as this blog post: http://bergie.iki.fi/blog/createjs-in-2013/ . There already is a PHP library (create.php - https://github.com/flack/createphp ) which aims to help integrating create.js into existing applications/cms. I'd absolutely love to see this feature in an upcoming version of processwire (even though i will also keep using processwire it if there won't be in-page editing ). Best regards, Felix1 point
-
I’ve been working on a simple admin theme. I originally just wanted to add a simple dashboard area on the home page to display some quick links to key actions and documentation for clients, but I ended up doing a whole theme. The main focus of the theme is for the client / editor role, so it’s not been optimised for the developer usage yet. There are a few enhancements which are aimed at clients (opening previews in a new window, showing tree actions on hover). I have also tried to optimise it for mobile layout. You can see a preview on this video It’s using the Bootstrap framework and Open Sans font. The main issues I currently have are a conflict with the Bootstrap framework scripts and the older version of Jquery that ships with the PW admin. If I upgrade to Jquery 1.8.2 a lot of PW admin functionality breaks (sorting, ask select, modals). If I stick with the currently shipped version of jQuery 1.6, the bootstrap scripts do not work (drop downs, message alerts, mobile navigation). The other big issue, is I made a few simple hacks to some core js files (/wire/modules/Process/ProcessPageList/ProcessPageList.js, and /wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js) - this was mainly to insert extra css classes here and there or to show if the tree has children. Is there a better way to do this? Other issues I am thinking about Is there a way to modify the “add new page” workflow? So when the user adds a new page, I’d like to change the default “You are adding a page using the …” message. Maybe this could be an additionally template field called “instructions” or “”details” ? It could be a used as a kind of “templates documentation”, which could be used to document the project for other devs and designers and for the clients / editors. How can you modify the login screen without overriding this file (/wire/modules/Process/ProcessLogin/ProcessLogin.module)? Also not to sure if having two save buttons is good for usability - maybe I will just have one in the header and make it fixed as you scroll.1 point
-
Hi all, I'm writing a utility module to send basic payments to PayPal and then to validate the IPN response that PayPal returns. The module is a simple wrapper around their Website Payments Standard api. You can view the module here: https://gist.github.com/4493175 When you initiate a payment the customer is redirected to PayPal where they complete the transaction, and then returned to the "thank you" page as set in the module settings. PayPal sends a copy of the transaction and its status (authorised|cancelled|refund etc) to a specified listener. Once your site receives this copy, you validate its authenticity by sending it back to PayPal who confirm that they sent it to you. So far so good. The problem I am having is adding a hook to the method that processes a successful payment validation from another module. I'm trying to use this code to hook the method but having no luck: /** * Initialise the module * */ public function init() { // Add a hook after to update member role and expiry date $this->addHookAfter('PaymentGatewayPayPal::processIpn', $this, 'processPayment'); } /** * Process the successful payment * */ public function processPayment($payment) { mail($myEmailAddress, "Test payment processing", "This ran"); } Can anyone suggest where my hook might be going wrong? I'm also keen on any general tips on how the module could be made more robust before I release it. Best regards, Stephen1 point
-
I was thinking of a way of creating custom admin pages without having to create a process module or having to use the $wire object. I came up with a process that is actually very simple (although I think it would be better to create a module for having this functionality). Here is how: (This will work with the default admin theme, but should also work with other themes) Go to your /site/templates-admin/default.php (if you don't have it, copy the /wire/templates-admin/ directory to /site/) and change this line <?php echo $content?> to this <?php if($page->template===$templates->admin){echo $content;}else{include($config->paths->templates.$page->template->name.".inc");}?> Then, go to the /site/templates/ folder and create a file named "custom.php" with this content <?php include($config->paths->adminTemplates."default.php"); Our setup is ready Now, to create a custom page in the admin: First, create the new page as child of /Admin/ and point to custom.php as the template file. To do this, when creating the template for the page, go to "ADVANCED" and write "custom" as the "Alternate Template Filename". Then, instead of creating a TEMPLATE.php file, as you normaly would, create a TEMPLATE.inc file. You can use all the API variables as you would in a normal template. Disclaimer: This is a proof of concept, and has still lot's of place for improvement. edit: changed from this if($page->process) to this if($page->template === $templates->admin)1 point
-
This is somehow related: https://www.acquia.com/blog/open-source-community-and-freedom1 point
-
1 point
-
Just bumping this as we have several new UK-based members posting in the forum now. For what it's worth, I'd still be interested in meeting up with some PW folks in the Manchester/Birmingham/Bristol area but perhaps there are now enough UK based users to allow for something like regional PW user groups? There are several folks based along the West Coast "corridor" (M5/M6) and another cluster in the London area. Whilst Ryan's conference is on hold, perhaps we should arrange some meetings of our own in 2013 -- even if they are mainly social events with little additional planning.1 point
-
Fixed another issue with not being able to see quotes or code blocks when editing - now you can see them which makes it easier to edit them. Note for all: Use the quote or code buttons in the editor as they're the best way of adding either reliably. They've improved them in this version. Heck, even code indents work with them EDIT: Nico - I fixed the nav colour to match the site too.1 point
-
I haf to not only clear cache but also clear cookies miamm Its cke ediotr not tiny wanted to add1 point
-
[quotamos]ere be field with fieldtype "stats" that doesn't have inputfield? Or is inputifield always required? Of course it could be just dummy&hidden. Just thinking if Adam would implement "Stats" fieldtype for his trac[/quotamos] u.see conscat fieldtype no inputfeld http://modules.processwire.com/modules/fieldtype-concat/1 point
-
@apeisa: Damned, I did a little 'refactoring' just before committing... Seems I've broken it down, have to take a look at it a bit later (found one bug right away, but it didn't fix the whole issue). Sorry everyone. Fail. And that naming. I couldn't come up with a good name - but it was too obvious. We'll see if this module gets a third name before it becomes stable.1 point
-
Same to you with bells on Luis & Tina - might be a cache issue? Try a few CTRL & F5's to see if it sorts it please as there was an issue yesterday briefly when a lot of people were online that I fixed.1 point
-
Ouch. Write a simple cronjob which dumps all databases to a Dropbox folder - or other online service. Saved me a couple of weeks work in 2012. My biggest fail had to be working on a very extensive design for 1.5 week locally before moving it on the network drive (which runs automated backups). Then I decided to delete it since I copied it. Then I realized I was working on the network drive. The backup were about to run. I almost fainted and actuallyactually felt sick. Luckily the projectmanager was able to postpone the deadline with client. Since then I started using Dropbox and (since PW also git) so I can recover most stuff.1 point
-
you.can move admins themed to /site/templates-admin/ no mas.worry on upgraded1 point
-
Really enjoying the forum updates, look and feel. Pete you did a fantastic job with this transition. Thanks again for being great.1 point
-
Hi Ryan This is useful stuff that could apply to a lot of situations I suspect If you ever get some time, a small tutorial would be really useful - if you want to do it as quick bullet points I will be happy to write it up. Joss1 point
-
Images are stored in "site/assets/files/{page_id}/your_filename.jpg". Go to the page in the Admin and right-click on the Image/Thumbnail -> Open in new Tab. This should open the image, you can now save it via Browser. (Not sure if this is the way you meant with "download")1 point
-
1 point
-
No they don't, but minor updates usually result in smaller template edits so it's just a bit of a hassle the first time you create a template - maybe when I win the lottery I'll pay Antti to build on his PW discussions module for a year solid I've added some padding now.1 point
-
1 point
-
If you do use SSL certs for parts of the site, and if those parts are not 'public' you could try using self-signed certs as you probably don't need to go to the expense of getting anything fancy from a "trusted" third party.1 point
-
One thing I've done a lot before (with less-pretty galleries ) is to make the first image in the images field represent the whole gallery. I'm pretty sure a lot of people do this, but it's easily grabbed with: echo $page->images->first()->url; Which everyone probably already knows1 point
-
I use this excellent golden module by apeisa master: http://modules.processwire.com/modules/process-redirects/1 point
-
No problem - if something seems too hard in ProcessWire there's usually an easier way1 point
-
@Pete, hi Pete, thanks for helping. I wanted to create the module since some friends want to be able to add page-lists at will, simply by defining the parent-page and the limit of pages. Maybe it's because they're used to another CMS. And as Soma mentioned later, it's not meant to be a front-end form, the inputfields simply get the details then output them where I need them in the markup (or they're supposed to, anyway). @Soma, thanks for helping as well. After it didn't work I imagined it would be harder than I thought, maybe it's better to put this project on hold until I grasp PW's basics. Your solution could work well, although I was aiming to create back-end interface where users simply select the parent page, the limit and the code is outputted where needed, for ease of use (no code involved). But I think I'll show them PW is different and how they can make it even more awesome. Plus as @nik and @netcarver said, what a great explanation Soma, thanks for taking the time to deal with me. Thanks to all...1 point
-
Mike, For this example, I'll assume your field is called "images". To get the first image, you would do this: $firstImage = $page->images->first(); To get a numbered index, you would do: $nthImage = $page->images->eq($n); // where $n is a 0-based index Or, of course you can iterate the images too: $n = 0; foreach($page->images as $image) { echo "Image $n - " . $image->url; $n++; }1 point