Jump to content

ryan

Administrators
 View Profile  See their activity

  • Posts

    16,715

  • Joined

  • Last visited

  • Days Won

    1,517

 Content Type 

Everything posted by ryan

  1. ryan
    I'm not clear what you mean about "deleted all my pages". At least, this is not usually a step one would take when moving a site to a production server. So I think I may misunderstand what you mean. Can you clarify?
  2. ryan
    When you get 404s for everything but the homepage, that means the .htaccess file is not working. Edit your .htaccess file and paste in some garbage at the top, like "alkjaelfkjaef" and save. Now view your homepage. If you get a 500 error, your .htaccess is working (and you should look at the RewriteBase Nik mentioned). But if your homepage still works, then you know your .htaccess is not working. At this point, you need to tell your web host to turn it on. Or if you run the server, you need to add "AllowOveride All" to your httpd.conf for the account.
  3. ryan
    That makes sense. Perhaps what we really need are rows of two inputs each. Though that might be more trouble than it's worth in this case.
  4. ryan
    Pete this upgrade is great. I can actually enter code and have the formatting retained. I can even go back and edit it, and all is good. It looks to me like IP.Board has fixed the bugs finally!
  5. ryan
    The field 'process' is a system field, so you won't see it in the admin interface as an option to add to a template unless you have $config->advanced=true; in your /site/config.php. You can also add it from the API side.
  6. ryan
    You can hook before Fieldgroups::save or Templates::save. public function init() { $fieldgroups->addHookBefore('Fieldgroups::save', $this, 'addProcessField'); } public function addProcessField(HookEvent $event) { $fieldgroup = $event->arguments[0]; if(!$fieldgroup->hasField('process')) $fieldgroup->add('process'); }
  7. ryan
    I think this is definitely a great idea for a module. But it's also true that it kind of goes against the whole markup agnosticism, and is pretty limited when you consider the broad range of inputs possible with Inputfields. In the context of ProcessWire, it's only a partial input solution. Most importantly, front-end editing goes against content portability and is thus not a best practice. We should be abstracting content away from design, not tightly coupling content into it. I think many using a front-end solution would try to design and fit their content for the space they are typing in. Then the content is a mess when the site goes mobile, responsive or gets redesigned, etc. Promoting content portability is an important job of a CMS, and front-end editing is not good for content portability. That being said, it's great eye candy and there are plenty of cases where I think the benefits of it would outweigh the negatives too. As a core solution, I think front-end editing is a bad idea. But as a modular option for those that want it and understand the tradeoffs, I think it's a great idea. I can think of cases I would use it myself too.
  8. ryan
    Great article. Nice to see Deane Barker from Gadgetopia (one of our forum members) quoted there too.
  9. ryan
    Great module, thanks Nik!
  10. ryan
    I'm happy to add this to the default admin theme too.
  11. ryan
    This would be pretty easy to add to any admin theme: <body class="<?php foreach($user->roles as $role) echo "role_" . $role->name . " "; ?>"> But whether it's advisable is another question. If you don't want the user to have access to something, it's best that the logic of the page knows not to even display or accept input to it. Otherwise it's a potential security hole. Though for non-security related display adjustments, it seems like a fine way to go.
  12. ryan
    While there are certainly more and better things one could do with access to text files (i.e. importing to DB), it certainly wouldn't be hard to pull in a text file directly from your template and display it on every page view. At the simplest level: echo file_get_contents("/path/to/file.txt");
  13. ryan
    Really enjoying the forum updates, look and feel. Pete you did a fantastic job with this transition. Thanks again for being great.
  14. ryan
    The ability to edit entries on the front-end is certainly something you can do with ProcessWire. And it's rather simple from the API side. We are doing it on the modules.processwire.com site, for example. But what you are talking about sounds kind of like a form system that is itself a CMS of sorts. The broad scope of such functionality doesn't really fit with what Form Builder is meant for, though maybe there are some things in that regard we could pursue in the future.
  15. ryan
    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.
  16. ryan
    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.
  17. ryan
    I think this seems like a nice format too. I guess what I was trying to get at with the format I recommended was the familiar "if => then" statement. "If the saved page matches this, then clear this cache." I start to have a little trouble when the logic gets to: "If the cache is this and if the saved page matches this selector, clear it."
  18. ryan
    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.
  19. ryan
    I see my message above got quoted from an EE-related Twitter account. Just want to clarify that I have no idea what actual reasons prompted EllisLab changes or what their strategy might be. But just find the changes interesting and am making guesses. Another thought that crossed my mind is that it could have all been prompted by some new investors. But my guesses probably sound silly to someone that actually knows about it all. Maybe someone else can chime in about it.
  20. ryan
    No, it's 697. But I'll get around to it.
  21. ryan
    echo "test"; echo "test"; echo "test"; echo "test"; echo "test"; echo "test"; echo "test"; echo "test"; echo "test"; Able to complete this request due to no error.
  22. ryan
    Sounds like IP.Board doesn't make their upgrades very easy. Thanks for your time and expertise in getting us up to date. I'm really liking the new look. One minor point I wanted to mention is that the edges of the masthead are flush on either side of the screen when they should be padded at least 10-15 pixels or so like the rest of the interface. Screenshot attached.
  23. ryan
    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.
  24. ryan
    We haven't accounted for a site-wide count in the API. But you could still do it fairly easily with an SQL query: $result = $db->query("SELECT COUNT(*) FROM field_comments"); list($numTotal) = $result->fetch_row(); echo "<p>There are $numTotal total comments</p>"; $result = $db->query("SELECT COUNT(*) FROM field_comments WHERE status=0"); list($numPending) = $result->fetch_row(); echo "<p>There are $numPending comments waiting approval</p>"; $yesterday = strtotime("yesterday"); $result = $db->query("SELECT COUNT(*) FROM field_comments WHERE created>=$yesterday"); list($numNew) = $result->fetch_row(); echo "<p>There are $numNew new comments posted since yesterday</p>";
  25. ryan
    I don't think there's any need for selectors to contain question marks here. While it's feasible someone may use one for performing an exact search on something like "title=why eat pastured eggs?", I really don't think that's a likely selector need in this context. I think we can safely not worry about question marks in selectors here. For separating selector from the name/regex, I was initially thinking just an explode('?', $line); but that won't work since regex's often contain question marks. But something like this should work: $pos = strpos($line, '?'); $selector = substr($line, 0, $pos); $line = trim(substr($line, $pos+1)); // reduce line to the part after the ? if(substr($line, 0, 1) == '/') { // if it starts with a slash (delimiter) we assume regex $regex = $name; $name = ''; } else { // otherwise we assume cache name $regex = ''; $name = $line; } The test to determine whether it's a regex or a name would just be to see if the first character us a slash "/" (the most common PCRE delimiter). So the way for the user to say they want something to be a regex would be the same way they'd do it elsewhere, which is to start and end it with a delimiter. Though in this case, we'd limit them to "/" as the delimiter, which seems like a perfectly fine limitation here to me.
×
×
  • Create New...