So you create a category, it saves but it loses the slug?

Can you try with English characters please, see if the same happens.

I am not sure if non A-Z will be supported in the URL. Does this work with non-CodeIgniter web-sites?

Yes.But English characters is OK.Maybe the url_title function does'nt support chinese string.I try to use wordpress's sanitize_title_with_dashes function.It can not work either.The server responsed that it is a bad url.The url like http://localhost/pyrocms/admin/categories/edit/%25e9%25a5%25ad%25e9

Thats really not a good URL to have. No users, bots or ANYTHING would see that as anything other than gibberish.

Not sure what to do about this.

Could you send me what you have so far? I will try and have a look this week. email@philsturgeon.co.uk.

May I ask you a question?Thank you.Why use slug instead of primary key?Because I found the news module do work using primary key regardless of which language.

Slug = text representative that shows both users and crawlers what the content is.
ID = number in the database.

Of course a number works in every language, they are always the same.

I wouldnt want to ruin SEO for all languages with English characters, just to support non-English languages. Perhaps I can look into using primary key for non-A-Z based languages?

Oh,I see.Someone have get a solution.He translate the Chinese Character into pinyin.Pinyin use A-Z just like english.But it is a little complex.see http://www.moon-blog.com/2007/08/wordpress-plugin-chinese-pinyin-slug.html

I have sent you the catagories table.Please check it.Thank you.

Yes,You are right.I use hash code in slug for non-A-Z based languages.It do works.Just modified url_title.Thank you.

So this one can be closed ?

No. News articles create a slug automatically, based on the title. These slugs will be broken.

you have to send the ID number since the ID is unique , i already got issue opened check it .i also modified the cms version work this way , if you are interested

Meabed: We cannot just stop using slug's and swap everything to an ID, there is a reason we used slugs in the first place.

Should we allow a human-pickable slug for everything using a slug? Can auto-suggest with JavaScript and only allow A-Z, 0-9, -, _.

Good idea.

It will show html code in article.It seems htmlentities function must change into html_entity_decode function both in view.php and admin/preview.php under news module's view directory.

I tried htmlentities(stripslashes($article->body),ENT_COMPAT,'UTF-8') and it started showing HTML in my posts.

Are you suggesting that using: html_entity_decode(htmlentities(stripslashes($article->body),ENT_COMPAT,'UTF-8') ) will work? >.<

yes.It works.

wuts: I need a test plan for this, can you send some characters that are currently breaking?

Any Chinese Character may cause breaking.Such as blow:
小作者最喜欢的动画就是火车侠了。在他的想象中，天空中的白云像握紧的铁拳，太阳不断喷射火焰，奥特曼和他的遥控器从天而降，一列超长火车急速飞驰在轨道上…直升机升空，准备战斗……所有人！全速！前进！

小画家首先勾画出了他最爱的火车侠，尖头长身，便于急速前进。并用偏冷的绿色搭配温暖的黄色渲染了车身，可爱质朴的短粗线条画出了铁轨。

Has been fixed in v0.9.6.2 was an issue with the multi-langing of the "new item" type buttons.

Done.

Please report an error in full before you try to provide a fix.

Do you have screenshots or error messages for me to look at?

the error if i make for Example category in with Arabic title , so the function url_title that take the string and convert it to title by placing dashes instead of spaces .etc ..
so when u make it in Arabic the Slug become null !
so whenever you want to Edit or delete category it won't be don't cuz category->slug = null !

Well instead of using ID for edit and delete, we need to solve this problem of null slugs.

What are your suggestions for that? The slugs need to exist for news, categories, suppliers, etc.

ok i will try to rewrite the title_url function to rewrite the utf8 things and ill post here when ever i got working version asap

I found Solution by removing $('a[rel*=modal], a.modal').livequery(function() { in admin.js file !

Meabed: You cant just delete random bits of code to fix one error. That will stop all modal links from working!

I'll look into this error, thank you for reporting it, but please leave the solutions to us.

This should be fixed in v0.9.7, can you confirm?

It didn't Work yet ,
Meabed: You cant just delete random bits of code to fix one error. That will stop all modal links from working!
btw am Experienced web Developer am not a kid playin around :)

Deleting this will stop modal i know ! but you can simply change the modal links because it IE says missing String ! so its maybe the selector missing something ?
Also by Deleting this Line , i got no problems At ALL !and the script working fine ! ALL functions !

I guess that when Internet Explorer is the only one complaining it's IE's fault ;)

If it breaks modal windows then not everythin works fine! We'll find a proper fix but please provide some screenshots or error messages from firebug. Or a step by step approach of how to recreate this error as I cannot recreate it.

yes indeed its IE fault , i don't like IE also , but all the people still using it :)
The Error when u login to the control panel in IE 7 , the style is ok , the sidebar menu is different ill post screen now , also the Table Sorting Doesn't WORK !
Screen Shot : http://yfrog.com/5z43780055j

I cannot test this on IE7, but from the screenshot I am not worried about those issues. If it WORKS in IE7 then that is good enough for me.

Other than a few slight display issues, the only problem here it seems it table sorting. Short of removing the line for modal windows, if you find a proper fix then please post it here.

Comment those lines , i know it will remove the Loading image from the Facebox , but it still have fading effect .

    // Facebox modal window
    //$('a[rel*=modal], a.modal').livequery(function() {
//      $(this).facebox({
//          opacity : 0.4,
//          loadingImage : APPPATH_URI + "assets/img/facebox/loading.gif",
//          closeImage   : APPPATH_URI + "assets/img/facebox/closelabel.gif",
//       });
//  });
    // End Facebox modal window

it working like this :)

Solved. The IE7 JS engine does not support , at the end of a property list, but Gecko engines and WebKit do. Fixed in master.

While this is possible, its an ugly non-modular solution.

This is something we will address when the modules move over to the Database. Then they can be easily ordered via drag/drop and the order can be saved.

Sorry to close this one, its just something we cant do right now.

Im not sure what the problem was here. Can you provide a screenshot?

when u click on Settings in menu / 3 times or row , try click again , it will not expand !
that's it , because the li still has active class .

Neither is "more accurate". em is relative to the font size, which we reset to a consistent default, meaning that neither IE or FF will be any different.

This is not an issue.

You can watch the differences in FF and IE if you used em !!! and try it px there is no difference at all !

Yes you could!

:) ok ill make it then you put in the next release:)

Thank you for the bug report but this has already been fixed and pushed to master.

Please before posting a bug report could you have a quick look at the history or directly at the file in question just to see if it has been fixed already? Saves everyone time and means you can just grab the new code instead of waiting for a fix.

Cheers,
Phil

A good point. The INSTALL file contains:

chmod 777 -R application/cache

but this is missed for users installing. Simplepie will have the same issue.

Added to internal tracker, we had a similar ticket for SimplePie already.

What page is this on? Settings should be autoloaded so shouldnt be an issue.

Ahh shit, gotcha. It is because it shows as lowercase in the Git repo. For me it is uppercase, but it wont notice the difference when I commit. This will only affect some OS's luckily.

Simply rename it in /application/modules/core/settings/libraries/settings.php to Settings.php

I will delete the file and recommit with a capital name.

Ok, renaming goes around but then I get issues in MY_Router:

Severity: Warning
Message: include_once(application/modules/core/settings/libraries/   settings.php): failed to open stream: No such file or directory
Filename: libraries/MY_Router.php
Line Number: 158

Severity: Warning
Message: include_once(): Failed opening 'application/modules/core/settings/libraries/settings.php' for inclusion (include_path='.:/usr/share/pear:/usr/share/php')
Filename: libraries/MY_Router.php
Line Number: 158

I guess there's settings.php being called around somewhere.

So I don't know if you should rename settings to Settings.php in this case..

I'll comment back if I have any idea

EDIT : Renaming to Settings AND change "settings/Settings" in the autoload file goes around and gives a different (easier?) problem:

A Database Error Occurred
Error Number: 1146
Table 'pyrocms.settings' doesn't exist
SELECT slug, type, IF(`value` = "", `default`, `value`) as `value` FROM (settings)

And I don't have that table. I believe I'm missing quite a few tables here because I got stuck on Step4 (finished the installation there and changed database.php manually)

Sorry for the confusion.. I have fixed the database and having "Settings.php" file and "settings/Settings" on autoload will reproduce the same problem above on MY_Router.php line 158.

If the install failed half way through then you would be missing tables yes. Please can you wipe and start again after this mornings push, as it has taken care of several bugs and made good progress on the interface.

Also, make sure you are using Settings.php and have settings/settings.php in your autoload.

Fixed in this mornings push.

A user forgot to clear his cache after upgrade.

Also due to user not clearing cache.

All guessed paths will add missing slashes to the start or end of the path, including in the base_url.

Well god knows how he is getting that, there is no line 134!

The link is dead :|

The issue was solved I believe. He has now set up PyroCMS perfectly so... may as well close this.

Add them to the sidebar instead.

Thats not a helper. Unless we have a "categories" widget. Get on with Yummy dude!! :-p

I can send you the Yummy library, it's already quite mature.

Great. Can Yummy have multiple instances of the same widget?

I am guessing that the navigation module will be pretty much pointless after we make a navigation widget.

Currently Yummy can't run the same widget multiple times. You also shouldn't replace the navigation module with a widgetized version. If you do so the navigation menu will always pop up in the sidebar.

We'll need multiple versions of widgets. They will also need to be added to "widget areas" which are basically the same thing as navigation groups.

With a link menu widget there really is no reason for a navigation module as it would do the same thing and make ordering menus within widget areas impossible.

Hm...I'll see if I can add the ability to run the same widget multiple times. I'll also add areas for the widgets.

Widget areas are now supported !

Sweet! Hopefully that works with multiple widgets? As I said, we need to be able to put a "menu widget into sidebar", a "menu widget into footer", a "rss into left-nav", etc. They need to be multiple and moveable and go pretty much anywhere.

I sat down for a few minutes and thought about it, and as stupid as I am sometimes I came to the conclusion that widgets can have multiple instances in the same area.

Currently you can't put the same widget into multiple different areas, but I'll add this option tomorrow.

See my latest commit :)

Nicely done. Also, could you take a look at the Verifier.php class in the libraries folder? It does a few things such as checking for curl, checking PHP versions, etc.

Would be good to make sure that some of these things are handled by the installer instead of lettng a user install then being confused.

Also, it is still hard-erroring on mysql failure.

Bloody good so far though. :-)

This ready for testing?

I haven't added any extra features to the installer yet :)

Not tested this one. Can somebody confirm it works?

What's the status of this issue ?

You should have a look at my new branch issue_15 that I've pushed now ;)
Now the products module should work fine overall

BenneX

I have added HelpfulParser. This will have to do for now and we can improve it as we go.

I'm calling this done, nobody has mentioned any issues with it and it works fine for me on Mac and Ubuntu.

Widgets ? :)

1.) has been done. Will do 2 another time.

2.) I've added the flash-messages in the english lang file.
Fixed Files:
comments/controllers/admin.php
comments/language/englsh/comments_lang.php

It's just needed to merge the branch into master ;)
Okay, I close this issue for now.

BenneX

jQuery UI Tabs and Facebox hate each other when viewed in IE7 but it just happens to be a TinyMCE line they complain about. Comment out facebox and jQuery UI works fine.

I have to ask if anybody really cares. I will not waste a second of my day supporting IE6 but IE7 might be an idea...

http://docs.jquery.com/Core/jQuery.noConflict

I've pushed a branch named "issue_36" with the fixed file, which just need to be merged into master.

There was a little syntax error, which also can be fixed manually.
Just open the following file:

pyrocms/application/modules/navigation/controllers/admin.php

and go to line number 156 or search for the following code snippet:

$this->session->set_flashdata('success', $this->lang-line('nav_link_delete_success'));

and replace it with the following code:

$this->session->set_flashdata('success', $this->lang->line('nav_link_delete_success'));

BenneX

So far the only thing that needs to be fixed is the stupid bug that prevents a widget from being executed twice, and god knows why it isn't working.

The widgets library has been added. The next step is to integrate it into the system.

Quick question, why can't I extend the default controller or MY_Controller ? This is required by the library, but whenever I do so I get the following error : http://i29.tinypic.com/2z3nqwy.png

Oh and by the way, where do you want me to load the library ? Right now I'm loading it at the top of the PyroCMS template (which is really, really stupid).

Autoload? It will be used on all pages so seems fair enough.

Not sure about the loading issue. Include the widgets class in MY_Controller?

Hm, didn't thought about that :P

Not sure about the loading issue. Include the widgets class in MY_Controller?

I can't make it extend the Controller class or the MY_Controller class for some reason. Embedding it into the MY_Controller class would be rather dumb.

We already do this for Public_controller and Admin_Controller:

include(APPPATH . 'libraries/Public_Controller'.EXT);
include(APPPATH . 'libraries/Admin_Controller'.EXT);

So you want me to extend the Public Controller instead of MY_Controller ?

Fixed the problem using the get_instance() stuff. Not really fond of it, but it works.

get_instance is a good way of doing it. More logical and less hacky that my suggested method. :-)

Isn't there another way, besides the one you suggested or my solution ? I'm not really fond of having to use $this->CI->load->model and stuff like that. $this->load->... is much cleaner :)

I'd say this is the best way to go. This is how all of my libraries do it. Makes much more sense that extending controller.

Hm..I'll just leave it as it is :)

So the News Widget is finished, but the other ones aren't very clear to me.

RSS Widget

Internal or external RSS feeds ?

Twitter Stuff

How the hell do I use the Twitter model ? It doesn't make any sense :P

Links Menu

Use result_array() rather than result(), that way you'll get rid of the Std Classes. Other than that, is it possible to fetch the link groups using the name, rather than the ID ?

Currently the following widgets have been created :

Feeds (RSS and Atom)

Enables the user to display external RSS or Atom feeds. The feeds are parsed using SimplePie

Navigation menu

Shows the navigation elements for a certain navigation group (e.g. Sidebar)

Recent News

Shows a list of recent news articles.

Why use simplepie when we can just use built in SimpleXML?

Anyhow before making too many new widgets we need to worry about sorting out the db structure so we can have multiple widgets of the same type.

Because it's MUCH easier to use SimplePie instead of writing my own parser.

Anyhow before making too many new widgets we need to worry about sorting out the db structure so we can have multiple widgets of the same type.

I double checked the database and adding the the same widget multiple times works perfect, the only thing that needs some minor modifications is the library in order to make this work properly.

Version 1.2. 1.2 MB zip file

That is why it's better. Thats like fishing with hand grenades dude!

So you are basing your arguements on the file size of a zip package. Did you bother looking at the contents ? The actual library is just 380 KB (of which about 50% consists out of comments).

Seriosuly, don't base arguements on file sizes...

Still, RSS parse with simple xml is 20 lines of code. whats the point?

Because then you'll only be able to parse RSS, whereas SimplePie can also parse ATOM. I don't really see the problem, it works perfectly.

I assume .spc files are SimplePie Cache? You need to configure the library to store ALL cache in the main cache folder, NOT application/widgets/feeds/cache/*.spc

We don't need ANOTHER cache folder, just the one please.

This issue can be closed since all the widgets are created. The only thing left to do is to make a backend module and we're done :)

It's "Nederlands" in Holland :)

Hows this language coming along? I have changed the name and added the flag, all we need now is the extra files to be translated, and PyroCMS will support three languages! :D

When loading the dashboard you would fetch these results and store them in a variable (and output it). I think it's best to only do this for the default modules. If you would do this for every module the dashboard would probably become very slow.

For instance, you could use the following :

Model function (from my guestbook) : http://pastebin.org/10849
View file (also from the guestbook) : http://pastebin.org/10850

Pretty much fixed in this commit, though the dashboard message needs to be changed (and translated) : http://github.com/philsturgeon/pyrocms/commit/bfd50f7a98542bf55ed3dd51f269ead864fe8b17

Current features

• Comment stats (all,approved and pending)
• General stats (pages,users and news articles)

To do :

• The RSS stuff
• The server data

RSS support has been added in this commit : http://github.com/philsturgeon/pyrocms/commit/e329670aa0614d3c816a960d711308a33f436774

Sorry Ignited this was meant to be for you.

I have so far only checked the code looking at the commits and so far it needs lots of improvement in the quality of the coding. This needs to be using lang files and there are a few other comments on your commits.

PLEASE do not randomly assign yourself issues and commit half finished work to the master without running it by myself.

I wouldn't do it if people would do their homework. I'm not going to work on a project where most of the project members do jack shit.

They do what they can when they can. I am looking into ways to improve communication but its not the point. If you want to work on a new issue talk to me about it so we can plan how its going to be done. I REALLY dont want work that I have no idea about being thrown into the master.

If random work was thrown into branches... thats a different matter! :)

Home brew ! The taste of home made cookies is always better than buying it in the local bakery store :)

Ok screw it we're going to go with mine. It currently allows view forums, view topics, new topic and is almost working with new replies. Then its just "Edit topic", "Quote" and the moderator tools and its ready to go.

On overloading it with features:

Surely Pyro's gonna need a private messaging system anyway? I'm sure a lot of the additional forum functionality can be abstracted into separate modules and used across the system. That way the forum module itself is kept relatively clean.

Private messaging and friends etc are already seperate modules I have used in other projects. When I mentioned this I was worried that if we start down a community path then I will end up cnverting the lot (as seperate modules) and will start moving away from the current core-purpose of PyroCMS: "Creating simple sites for personal and corporate use".

I have got a little bored of converting the forums module, but will find the motivation to finish it sometime I'm sure. :-)

You mean displaying of active and inactive comments for each module which uses the comment-module? I've started so think about that while scripting the backend-part. The problem was that the easiest way to solve this solution to use url-params. But I wasn't abled to parse url's like this: admin/comments/module_name/edit e. g. to differentiate between the modules... If you could give me a solution of this, I can extend the comments-admin for that issue ;) I just need to be allowed parse url's with the special syntax: admin/comments_module/module_which_use_comments/action

Anyway I just need the possibility to get the module_name for which the comments should be displayed. I'll have a look at this one again. Some basics still exists ^^

BenneX

I think we need to have a serious think about how to create links to modules from the UI anyway.

If we have a "item table" which had, module, uri, id/slug and then we created an id for that, we could use that link_id everywhere.

Basically the link_id wouldnt exist until somebody tried to use it. then it would be added to the database.

This could be VERY handy for creating links to photos, news articles, suppliers, etc because all we'd need to know is the name of the module, the URI it is using and the ID number of the object and it would work.

That would also mean that we can have multiple "things" to link to for a single module.

With me on this? Guys, opinions would be great.

Step back.

We're using a polymorphic association for comments, so everything that is commentable can be commented on, from a central "Comment" model, right?

Why can't we assign a "resource_name" to the module (so the Articles module would have an Article resource, or the Categories module have a Category). Then we just display that along with the ID?

Thats kinda what im getting at, just struggling on the details. We can give something a "resource_name" and assign that resource a URI structure and some DB joining details, but not sure exactly how. Got code blindness over this one so need some fresh eyes on it.

The reason it seems like I am overcomplicating things is for the simple reason of this is quite complicated and started a discussion on a bigger problem.

Problem 1) We have no way to know what the URL is of a commented item. The CMS used to store the URI string in the database as unique but this is no good when commenting on news as the URI slug can change.

Problem 2): It assumes that only one kind of comentable "thing" exists for each module. This wont be true in some more advanced cases.

Problem 3) (the bigger thing): We need some sort of structure for the entire system. This is what I am talking about when I say "things". If everything has shared meta-structure then we can build tree's, set permissions, create navigation, breadcrumbs, etc all very easily. Right now with all modules acting entirely on their own there is no way to create a user friendly system for any of these aspects, AND keep it modular.

We can discuss point 3 separatly, but it would drastically change how we handle this issue in general.

I tweeted an idea to phil several days ago, but it seems he missed it, therefore I'm showing it here :P

If we want to link everything together (or atleast give the possibility of doing this), the only thing you would need to know is the table and the ID of the row. Simply creating a parent field with the following structure : %TABLENAME%_%ID%. For instance, a comment could have the following in it's parent field : pages_2. This would refer to the page with ID number 2.

As I said, not all modules will only have one "thing" so this approach is no good. Also, how would you join using that? There is no advantage to that approach over having a hash/unique key with various fields stored for each row.

I still cant even think how to begin this one.

Seperate them with a comma. Joining is simple since you can create the syntax for the query based on the format.

<?php
$parent = $this->some_model->get_parent(); // Get the parent(s) of the current item. In this case it will return page_1

// Get the stuff for the syntax
$array    = split('_',$parent);
$table    = $array[0];
$id    = $array[1];
 
// Do something with the database
$this->db->query("SELECT * FROM $table WHERE id=$id");
?>

Seperate them with a comma. Joining is simple since you can create the syntax for the query based on the format.

<?php
$parent = $this->some_model->get_parent(); // Get the parent(s) of the current item. In this case it will return page_1

// Get the stuff for the syntax
$array    = split('_',$parent);
$table    = $array[0];
$id    = $array[1];
 
// Do something with the database
$this->db->query("SELECT * FROM $table WHERE id=$id");
?>

While I was workin on this module I've just thought about that issue and as far as I remeber I had a solution but only the problem with the uri routing and the parameters. I need to install the github stuff and could have a look at it again :)

Done!

Should this be applied at a "Themes" level?

Balls to that idea.

Looks pretty neat :)

Done.

Pfff....Weren't the languages based on the URL or something like that ? If so you could simply redirect to the English version.

Issue being, the code says if a page & language dont match, the page doesnt exist for you.

That is the fundamental logic and pages are listed with language next to them. They only happen to share a slug, but they are separate enteties.

Should we perhaps make them simply "a Page" with multiple content boxes for different languages? Then just say "[checkbox] Spanish is the same as English" to hide the input box for spanish, so it shares the English content, etc?

This could get confusing.

Multiple content boxes for different languages isn't going to work when you have many different languages.

People are stupid, the file is in there so read it. Anyways, I'll add that list.

also, fix the error “The dummy data could not be inserted, please verify your settings.”

That error should only pop up whenever the tables don't exist for some reason, but I'll verify it.

Issue fixed in this commit : http://github.com/philsturgeon/pyrocms/commit/799f0ba6c51444fe66e84a90a57a597691e85d22

Much better. I had to make a change to allow soft error handling for GD if it is missing but now the server information is very handy.

For the installer to be complete, we need to make it into a step-by-step system.

Step 1, show you the server information.
Step 2, tell you to permission your files
Step 3, take information from the user,
Step 4, tell them to re-permission the config files back, and give them a link.

The dashboard should be available via a link from all steps, along with a "Skip", "Next" and "Back" on appropriate pages.

I'm actually thinking of recreating the entire installer from scratch using CodeIgniter, it's too messy at the moment.

It's fine as it is if you just get it running step -by-step. even a barebones new application would be overkill for this.

Just get it running in steps and we're fine. :-)

No, I've decided to completely recreate the installer. It's way too messy right now. On top of that I want to add an option that lets users update their database without messing around in phpMyAdmin.

We really should not add any scaffolding or anything similar. Please keep the installer to its absolute basics, and we can create a "PyroCMS Pen-knife" which will contain random utilities that exist outside of the main installation at a later date, if it is required.

I would like a working full installer as soon as possible as I am getting multiple complaints each day from users having trouble with it. Some are actual errors, some are lack of understanding as the installation is not clear enough.

Making this work in steps is a good quick solution for v0.9.7 and you can re-code it in time for v1.0.

Sound fair?

Already started recoding it earlier today, spent the last 6 hours working on it. Currently in the process of finishing the last step. :]

I know you have been working on this all day but I had to do quite a bit of work before the public could be let near it.

Firstly, why did you include a 2nd installation of CodeIgniter?! And why did you have some crazy modular system in there? If it needed modules, use the same one as the rest of the site?

Also you forgot to remove the tabs for Upgrade and Maintenance so those have been replaced with step 1, step 2 and step 3.

The main page still had the upgrade and maintenance headers and text on it too, lol!

Finally, anyone without GD would not be able to install PyroCMS. I dont have GD!! I added a message to say "you match most of the requirements, continue if you dont mind shit being messed up" or something along those lines.

The main thing is we got there! This is now a VERY cool installer, thanks very much for the work on this dude.

Any you know what this means? We can have a multi-lingual installer now! :D

Dude seriously, cry me a river. The "crazy modular system" is the HMVC, and is almost identical to Matchbox. The tabs and all the other stuff have been changed in a new commit, so check that first before replying.

Finally, anyone without GD would not be able to install PyroCMS. I dont have GD!! I added a message to say "you match most of the requirements, continue if you dont mind shit being messed up" or something along those lines.

Finally, anyone without GD would not be able to install PyroCMS. I dont have GD!! I added a message to say "you match most of the requirements, continue if you dont mind shit being messed up" or something along those lines

It only retrieves the version. If it isn't installed it will tell you. I don't see the problem of this. I've listed some reasons for moving the installer to CI below :

• Much easier to manage
• Multi lingual
• Cleaner code. The original installer was horrible and made me sick every time I took a look at it.

Moving to CI was brilliant, but you havent explained why we had to have a second copy of CodeIgniter in the codebase. We can use the same one...

The main issue with GD was that it would physically stop people from progressing through the installer. I do not have GD and it was creating a session variable that would not allow me to progress. This has been modified.

HMVC seems pretty fecking nuts after looking at the code. It has CI_BASE extentions in the Controller library and all sorts of crazy shit. Matchbox would have been a better choice to keep things working in the same way, but ofc we dont need any modular system now.

I am just adding a few more changes and you can see what I am talking about. A "Complete!" page was required too.

The GD library is something that should be required since the galleries and the staff module depend on it (or is it using something else ?) If you don't have it you should install it, instead of modifying the installer.

GD library is not required in the same was a PHP or MySQL because it will work at a basic level without it. If I turn off captchas and dont actually use products, staff or gallery then I will be fine without it.

Remember we are trying to support as many people and as many environments as possible, at varying ranges of technical ability. Everything has to work for everyone, unless they are using IE6 :-p

Ah ok. The installer will show the following message whenever the server doesn't passes the validation process for a full 100% :

Your server meets most of the requirements for PyroCMS to run properly. This means that PyroCMS should be able to run properly but there is a change that you will experience problems. In most cases this this is being caused by not having the GD library installed.

I already had a message in for that, but that is fine when you have fixed the change/chance typ0. Lets write new issues for new problems on this one.

Didn't notice that typo, I'll fix it later today.

Currently taking a hone hour break because I had enough of coding for more than 16 hours in total (over the past 2 days). I'll scrap the current template (again) and make one based on the installer :)

I thought you needed to finish widget work first? I suppose if its only backend left then that is enough to get going on templates again right?

We can leave the widget backend to someone else. You have already bitten off more than you have time for by the sound of it. :-)

The frontend needed to be finished, which is pretty much done for now.

If you don't mind me commenting, I don't think any of the current templates (installer, default and admin) are particularly great.

It all needs to be consistent, cool and stylish. We can get away with something simplistic, because it makes it a lot easier to do for us and makes it a lot nicer for the end-user. I'll have a go at writing up a simple stylesheet and some nice valid XHTML for the installer, just as a test to see what you guys think.

In the end the idea was to make the same template for everything (or atleast make it look the same). The current default template does look like shit and is being replaced with a template based on the installer.

This one can be solved the old fashioned way, a theme-off! :-D

If you are both working on one anyway, we can see which is better and make that the default, the other can just be a cool extra theme to be included in the release. Would be good to have a few in the core codebase as varied examples of what we can do.

You don't need a plugin for gravatars :)

Of course you do. You should NEVER refference a third-party website in your codebase unless it is wrapped in a function.

http://codeigniter.com/wiki/Gravatars/

Something like that, but renamed to avatar() would be fine. That way we can switch to any proivder down the line.

No you don't. Just chuck it in a helper. Plugins should only be used when you have additional resources. Getting a gravatar only requires the building of a URL, and an email being passed to it.

The wiki article I linked to was actually a helper, but if you check the manual for plugins:

Plugins work almost identically to Helpers. The main difference is that a plugin usually provides a single function, whereas a Helper is usually a collection of functions. Helpers are also considered a part of the core system; plugins are intended to be created and shared by our community.

It is a simple feature, just wrap it somehow, dont care which.

Still having this problem in PyroCMS v0.9.7.3?

Yes, still showing the same errors.
The Info I get is:

HTTP Server Settings

Your server software Apache (/w mod_rewrite) is supported.
PHP Settings

PyroCMS requires PHP version 5.0 or higher. Your server is currently running version 5.3.0, which is supported by PyroCMS.
MySQL Settings

PyroCMS requires access to a MySQL database running version 5.0 or higher. Your server is currently running a version which could not be retrieved and the client library version is mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27 $.
GD Settings

PyroCMS requires access to the GD image library for several tasks, such as resizing images, but it is not installed.

You are currently running version 2.0.34 of the GD image library.

It looks like this script is trying to create the asset_folder table twice as well.

i did also have almost the same problem
mine were 2 tables: asset and asset_folder
i removed the double create table (both underneath create table user)

also i recall there were couple of tables missing their fields or settings
for example:
- inside create table settings: missing set('password') on field type - table navigation_links missing field target

if you guys know more of this mistakes, please share them with us too

thanks for this great ci cms

one more problem
on mac, using mamp, i can install this cms almost smoothly
but when i try to install pyrocms on windows, using wamp
after step 4, it just stop and got back to step 4 again
asking me to insert database name, etc
please help me out

Can we stick to one bug per issue please? Hard to track otherwise.

All of these bugs have been solved in the bleeding edge (current codebase) and some are fixed in v0.9.7.1 (mainly installer issues with step 4).

Thanks for pointing them out, enjoy Pyro!

This looks like you have a slightly out-dated copy of v0.9.7.2, or i need to push v0.9.7.3 more than I realized. Can you please download the current bleeding edge (hit source, the click download) and you should see v0.9.7.3-dev in application/config/constants.php, or at the bottom of admin panel.

This should take care of both of those bugs.

To explain, the main reason for the bunged up looking templates its because the v0.9.7.x branch uses short tags in the view files. I v0.9.7.3-dev enables short-tag rewriting in CodeIgniter config which fixes this issue, and v0.9.8-dev hjas had all short tags removed and replaced with full PHP tags.

Yes, after changing the constants.php file, all seems to work ok...

Well, not all... logout from control panel does not work (http://localhost/pyrocms/admin/logout) -it does nothing-, but logout from public zone works (http://localhost/pyrocms/users/logout)

But HEY, I can see it all now, and it is impressing me VERY much!!!

I did another test today, and the problem is still there. I get the following output : http://pastie.org/546691

Enabling short tags fixed it, however I'd say it's best to not use Shorttags at all.

Why the devil do we need to do that? I have spoken to the guy that owns this template and no only does he approve of us using it, but he has even made us a design for the pyrocms.com frontend!

I really think our time would be spent better working on features instead of re-skinning the backend.

It's your call, but I would still love to see an example of the template so I can use it as inspiration for the default template.

Well, I don't really like the backend theme, too... The first thing I'll do after the release is to rebuilt it. It doesn't look really nice and seems to have bugs, problems with crossbrownsing and isn't valid as far as I've seen =P Should be a topic, but first we should keep on the way to release 1.0 ;)

Agree with that. It's not only because it isn't valid and stuff, but using a ready made template for a backend is kinda lame really.

Lets try and fix the validity bugs and we can work on a sweet custom one when 1.0 is out. I realise this CMS is slightly fucked in IE7 and VERY fucked in IE6 but... I dont really care lol.

We shouldn't give a fuck about IE6, it's 8 years old and I couldn't care less about those complaining the site isn't working in IE6.

• What is the something and something_else class names all about?
• What does module_function method do?
• Where is this called?

Why dont we just extend layout library to check for view files within the theme folder that match the filepath?

if(file_exists( theme/current/views/modules/news/views/index.php ))
{
    whoop, use the new one
}

else
{
    use the old one
}

I thought we decided we would just strip out the float-left float-right rubbish and leave modules to be styled with module specific CSS which could be overridden by theme CSS with !important;

It's just a bunch of example names.

I thought we decided we would just strip out the float-left float-right rubbish and leave modules to be styled with module specific CSS which could be overridden by theme CSS with !important;

We didn't actually. On top of that that idea is just plain stupid since you would still be limited to the HTML structure, and there's no way of changing it other than modifying core system files. Simply said : A big no-no.

For instance. Say a user wants to have the date of a news article showing up at the bottom, without having to modify the module view files or adding really stupid CSS rules. That's simply not possible with the current system, but it will be with the new one.

Considering we now have this I'm closing this issue :)

This is the AJAXify plugin that loads only part of the page and has history enabled by using the hash tag as a unique URL. This stops a new page load but maintains history and bookmarks.

Fixed the last AJAXify related issue I could think of, language switching links now use the AJAXify hash tag so you get sent back to whichever page you are viewing, AJAXified or not.

Or we could do the following :

@author Yorick Peterse - PyroCMS development team @copyright Yorick Peterse - PyroCMS development team

Personally I think this is better.

@author Yorick Peterse - PyroCMS

is fine. We should be adding full doc-blocks to all our work really. I'll put this on the "Coding standards" wiki page.

Great. It's something that makes it look more mature :]

Is this a full fresh install? when did this start happening? Whats the URL?

Ray is having this issue as well. It's most likely caused by a buggy .SQL file, I'll copy whatever is in the settings table and post it here tomorrow.