Timeline for Integrating plugins in themes
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2011 at 11:51 | comment | added | kaiser | Addition: If you use an OOP approach, then you can also question if the class exists. The number of loaded classes it around 10% of the total functions loaded. | |
| Apr 11, 2011 at 20:59 | vote | accept | OleVik | ||
| Apr 8, 2011 at 18:10 | comment | added | kaiser | Ad 1) Serving plugins with themes imo is not a good idea. It's hard to copy files around (chmod) and else. In this case i'd suggest to simply integrate it into the theme. Ad 2) No, not really. But you could maybe add something like a versionnumber constant to every file and check against that and then only update the changed files. Seems a lot of work just to get this structure. Ad 3) See edit in A. | |
| Apr 8, 2011 at 18:07 | history | edited | kaiser | CC BY-SA 3.0 |
added 195 characters in body
|
| Apr 8, 2011 at 15:42 | comment | added | OleVik | 1) Yes, I take the point about bloat and excessive functionality. However, if I made them modular rather than integrated, they would serve the purpose of being included with the theme rather than having to be downloaded. 2) Is there any way to split a theme or parts of a theme into a Git-like system, so only differential upgrades are necessary? 3) As discussed with @Drew Gourley, the function_exists only comes into place on a top-level, to check for plugin existance. | |
| Apr 8, 2011 at 14:16 | history | answered | kaiser | CC BY-SA 3.0 |